about summary refs log tree commit diff
path: root/src/libstd/sys/windows
AgeCommit message (Collapse)AuthorLines
2015-01-29Auto merge of #21677 - japaric:no-range, r=alexcrichtonbors-2/+2
Note: Do not merge until we get a newer snapshot that includes #21374 There was some type inference fallout (see 4th commit) because type inference with `a..b` is not as good as with `range(a, b)` (see #21672). r? @alexcrichton
2015-01-29convert remaining `range(a, b)` to `a..b`Jorge Aparicio-1/+1
2015-01-29`for x in range(a, b)` -> `for x in a..b`Jorge Aparicio-1/+1
sed -i 's/in range(\([^,]*\), *\([^()]*\))/in \1\.\.\2/g' **/*.rs
2015-01-29Rollup merge of 21654 - FlaPer87:unify-impls, r=alexcrichtonManish Goregaokar-13/+6
2015-01-29Rollup merge of #21640 - retep998:rmdir, r=alexcrichtonManish Goregaokar-1/+1
`_wrmdir` is literally just a wrapper around `RemoveDirectoryW`, so let's just use `RemoveDirectoryW`. r? @alexcrichton
2015-01-27Merge remote-tracking branch 'rust-lang/master'Brian Anderson-70/+70
Conflicts: src/libcore/cell.rs src/librustc_driver/test.rs src/libstd/old_io/net/tcp.rs src/libstd/old_io/process.rs
2015-01-26std: Rename Writer::write to Writer::write_allAlex Crichton-70/+70
In preparation for upcoming changes to the `Writer` trait (soon to be called `Write`) this commit renames the current `write` method to `write_all` to match the semantics of the upcoming `write_all` method. The `write` method will be repurposed to return a `usize` indicating how much data was written which differs from the current `write` semantics. In order to head off as much unintended breakage as possible, the method is being deprecated now in favor of a new name. [breaking-change]
2015-01-26Make Unix and Windows impls consistentFlavio Percoco-4/+0
There are some explicit Send/Sync implementations for Window's types that don't exist in Unix. While the end result will be the same, I believe it's clearer if we keep the explicit implementations consistent by making the os-specific types Send/Sync where needed and possible. This commit addresses tcp. Existing differences below: src/libstd/sys/unix/tcp.rs unsafe impl Sync for TcpListener {} unsafe impl Sync for AcceptorInner {} src/libstd/sys/windows/tcp.rs unsafe impl Send for Event {} unsafe impl Sync for Event {} unsafe impl Send for TcpListener {} unsafe impl Sync for TcpListener {} unsafe impl Send for TcpAcceptor {} unsafe impl Sync for TcpAcceptor {} unsafe impl Send for AcceptorInner {} unsafe impl Sync for AcceptorInner {}
2015-01-26Make Unix and Windows impls consistentFlavio Percoco-9/+6
There are some explicit Send/Sync implementations for Window's types that don't exist in Unix. While the end result will be the same, I believe it's clearer if we keep the explicit implementations consistent by making the os-specific types Send/Sync where needed and possible. This commit addresses pipe src/libstd/sys/unix/pipe.rs unsafe impl Send for UnixListener {} unsafe impl Sync for UnixListener {} src/libstd/sys/windows/pipe.rs unsafe impl Send for UnixStream {} unsafe impl Sync for UnixStream {} unsafe impl Send for UnixListener {} unsafe impl Sync for UnixListener {} unsafe impl Send for UnixAcceptor {} unsafe impl Sync for UnixAcceptor {} unsafe impl Send for AcceptorState {} unsafe impl Sync for AcceptorState {}
2015-01-25Merge remote-tracking branch 'rust-lang/master'Brian Anderson-2/+115
Conflicts: src/libcore/cmp.rs src/libcore/fmt/mod.rs src/libcore/iter.rs src/libcore/marker.rs src/libcore/num/f32.rs src/libcore/num/f64.rs src/libcore/result.rs src/libcore/str/mod.rs src/librustc/lint/builtin.rs src/librustc/lint/context.rs src/libstd/sync/mpsc/mod.rs src/libstd/sync/poison.rs
2015-01-25wrmdir -> RemoveDirectoryWPeter Atashian-1/+1
Signed-off-by: Peter Atashian <retep998@gmail.com>
2015-01-25Merge remote-tracking branch 'rust-lang/master'Brian Anderson-11/+13
Conflicts: mk/tests.mk src/liballoc/arc.rs src/liballoc/boxed.rs src/liballoc/rc.rs src/libcollections/bit.rs src/libcollections/btree/map.rs src/libcollections/btree/set.rs src/libcollections/dlist.rs src/libcollections/ring_buf.rs src/libcollections/slice.rs src/libcollections/str.rs src/libcollections/string.rs src/libcollections/vec.rs src/libcollections/vec_map.rs src/libcore/any.rs src/libcore/array.rs src/libcore/borrow.rs src/libcore/error.rs src/libcore/fmt/mod.rs src/libcore/iter.rs src/libcore/marker.rs src/libcore/ops.rs src/libcore/result.rs src/libcore/slice.rs src/libcore/str/mod.rs src/libregex/lib.rs src/libregex/re.rs src/librustc/lint/builtin.rs src/libstd/collections/hash/map.rs src/libstd/collections/hash/set.rs src/libstd/sync/mpsc/mod.rs src/libstd/sync/mutex.rs src/libstd/sync/poison.rs src/libstd/sync/rwlock.rs src/libsyntax/feature_gate.rs src/libsyntax/test.rs
2015-01-24Add ffi::OsString and OsStrAaron Turon-2/+115
Per [RFC 517](https://github.com/rust-lang/rfcs/pull/575/), this commit introduces platform-native strings. The API is essentially as described in the RFC. The WTF-8 implementation is adapted from @SimonSapin's [implementation](https://github.com/SimonSapin/rust-wtf8). To make this work, some encodign and decoding functionality in `libcore` is now exported in a "raw" fashion reusable for WTF-8. These exports are *not* reexported in `std`, nor are they stable.
2015-01-23Set unstable feature names appropriatelyBrian Anderson-1/+1
* `core` - for the core crate * `hash` - hashing * `io` - io * `path` - path * `alloc` - alloc crate * `rand` - rand crate * `collections` - collections crate * `std_misc` - other parts of std * `test` - test crate * `rustc_private` - everything else
2015-01-21Remove 'since' from unstable attributesBrian Anderson-1/+1
2015-01-21Add 'feature' and 'since' to stability attributesBrian Anderson-1/+1
2015-01-21rollup merge of #21258: aturon/stab-3-indexAlex Crichton-2/+2
Conflicts: src/libcore/ops.rs src/librustc_typeck/astconv.rs src/libstd/io/mem.rs src/libsyntax/parse/lexer/mod.rs
2015-01-21Test fixes and rebase conflictsAlex Crichton-0/+2
2015-01-21rollup merge of #21444: petrochenkov/nullAlex Crichton-7/+7
Conflicts: src/libstd/sync/mpsc/select.rs
2015-01-21rollup merge of #21396: japaric/no-parens-in-rangeAlex Crichton-1/+1
Conflicts: src/libsyntax/parse/lexer/comments.rs
2015-01-21rollup merge of #21389: retep998/timerAlex Crichton-1/+1
Fixes #20943 and adds a test for it r? @alexcrichton
2015-01-21Fallout from stabilization.Aaron Turon-2/+2
2015-01-21Rollup merge of #21387 - retep998:hmodule, r=alexcrichtonBarosl LEE-1/+1
r? @alexcrichton
2015-01-19remove unnecessary parentheses from range notationJorge Aparicio-1/+1
2015-01-19Impl Send for Timer on WindowsPeter Atashian-1/+1
Fixes #20943 Signed-off-by: Peter Atashian <retep998@gmail.com>
2015-01-19Fix HMODULEPeter Atashian-1/+1
Signed-off-by: Peter Atashian <retep998@gmail.com>
2015-01-19Replace `0 as *const/mut T` with `ptr::null/null_mut()`we-7/+7
2015-01-19std::dynamic_lib: Fix Windows error handlingklutzy-0/+7
This is a [breaking-change] since `std::dynamic_lib::dl` is now private. When `LoadLibraryW()` fails, original code called `errno()` to get error code. However, there was local allocation of `Vec` before `LoadLibraryW()`, and it drops before `errno()`, and the drop (deallocation) changed `errno`! Therefore `dynamic_lib::open()` thought it always succeeded. This commit fixes the issue. This commit also sets Windows error mode during `LoadLibrary()` to prevent "dll load failed" dialog.
2015-01-17auto merge of #21132 : sfackler/rust/wait_timeout, r=alexcrichtonbors-0/+51
**The implementation is a direct adaptation of libcxx's condition_variable implementation.** I also added a wait_timeout_with method, which matches the second overload in C++'s condition_variable. The implementation right now is kind of dumb but it works. There is an outstanding issue with it: as is it doesn't support the use case where a user doesn't care about poisoning and wants to continue through poison. r? @alexcrichton @aturon
2015-01-16Rewrite Condvar::wait_timeout and make it publicSteven Fackler-0/+51
**The implementation is a direct adaptation of libcxx's condition_variable implementation.** pthread_cond_timedwait uses the non-monotonic system clock. It's possible to change the clock to a monotonic via pthread_cond_attr, but this is incompatible with static initialization. To deal with this, we calculate the timeout using the system clock, and maintain a separate record of the start and end times with a monotonic clock to be used for calculation of the return value.
2015-01-14auto merge of #21061 : japaric/rust/range, r=nick29581bors-1/+1
2015-01-12Change Mutex to use SRWLock on Windows.Peter Atashian-83/+49
Signed-off-by: Peter Atashian <retep998@gmail.com>
2015-01-12cleanup: `&foo[0..a]` -> `&foo[..a]`Jorge Aparicio-1/+1
2015-01-11Rename AtomicInt and AtomicUintSteven Fackler-4/+4
Change any use of AtomicInt to AtomicIsize and AtomicUint to AtomicUsize Closes #20893 [breaking-change]
2015-01-08Improvements to feature stagingBrian Anderson-1/+1
This gets rid of the 'experimental' level, removes the non-staged_api case (i.e. stability levels for out-of-tree crates), and lets the staged_api attributes use 'unstable' and 'deprecated' lints. This makes the transition period to the full feature staging design a bit nicer.
2015-01-07More test fixes and rebase conflictsAlex Crichton-1/+1
2015-01-07Test fixes and rebase conflictsAlex Crichton-1/+1
2015-01-07rollup merge of #20721: japaric/snapAlex Crichton-3/+3
Conflicts: src/libcollections/vec.rs src/libcore/fmt/mod.rs src/librustc/lint/builtin.rs src/librustc/session/config.rs src/librustc_trans/trans/base.rs src/librustc_trans/trans/context.rs src/librustc_trans/trans/type_.rs src/librustc_typeck/check/_match.rs src/librustdoc/html/format.rs src/libsyntax/std_inject.rs src/libsyntax/util/interner.rs src/test/compile-fail/mut-pattern-mismatched.rs
2015-01-07rollup merge of #20654: alexcrichton/stabilize-hashAlex Crichton-3/+6
This commit aims to prepare the `std::hash` module for alpha by formalizing its current interface whileholding off on adding `#[stable]` to the new APIs. The current usage with the `HashMap` and `HashSet` types is also reconciled by separating out composable parts of the design. The primary goal of this slight redesign is to separate the concepts of a hasher's state from a hashing algorithm itself. The primary change of this commit is to separate the `Hasher` trait into a `Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was actually just a factory for various states, but hashing had very little control over how these states were used. Additionally the old `Hasher` trait was actually fairly unrelated to hashing. This commit redesigns the existing `Hasher` trait to match what the notion of a `Hasher` normally implies with the following definition: trait Hasher { type Output; fn reset(&mut self); fn finish(&self) -> Output; } This `Hasher` trait emphasizes that hashing algorithms may produce outputs other than a `u64`, so the output type is made generic. Other than that, however, very little is assumed about a particular hasher. It is left up to implementors to provide specific methods or trait implementations to feed data into a hasher. The corresponding `Hash` trait becomes: trait Hash<H: Hasher> { fn hash(&self, &mut H); } The old default of `SipState` was removed from this trait as it's not something that we're willing to stabilize until the end of time, but the type parameter is always required to implement `Hasher`. Note that the type parameter `H` remains on the trait to enable multidispatch for specialization of hashing for particular hashers. Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is simply used as part `derive` and the implementations for all primitive types. With these definitions, the old `Hasher` trait is realized as a new `HashState` trait in the `collections::hash_state` module as an unstable addition for now. The current definition looks like: trait HashState { type Hasher: Hasher; fn hasher(&self) -> Hasher; } The purpose of this trait is to emphasize that the one piece of functionality for implementors is that new instances of `Hasher` can be created. This conceptually represents the two keys from which more instances of a `SipHasher` can be created, and a `HashState` is what's stored in a `HashMap`, not a `Hasher`. Implementors of custom hash algorithms should implement the `Hasher` trait, and only hash algorithms intended for use in hash maps need to implement or worry about the `HashState` trait. The entire module and `HashState` infrastructure remains `#[unstable]` due to it being recently redesigned, but some other stability decision made for the `std::hash` module are: * The `Writer` trait remains `#[experimental]` as it's intended to be replaced with an `io::Writer` (more details soon). * The top-level `hash` function is `#[unstable]` as it is intended to be generic over the hashing algorithm instead of hardwired to `SipHasher` * The inner `sip` module is now private as its one export, `SipHasher` is reexported in the `hash` module. And finally, a few changes were made to the default parameters on `HashMap`. * The `RandomSipHasher` default type parameter was renamed to `RandomState`. This renaming emphasizes that it is not a hasher, but rather just state to generate hashers. It also moves away from the name "sip" as it may not always be implemented as `SipHasher`. This type lives in the `std::collections::hash_map` module as `#[unstable]` * The associated `Hasher` type of `RandomState` is creatively called... `Hasher`! This concrete structure lives next to `RandomState` as an implemenation of the "default hashing algorithm" used for a `HashMap`. Under the hood this is currently implemented as `SipHasher`, but it draws an explicit interface for now and allows us to modify the implementation over time if necessary. There are many breaking changes outlined above, and as a result this commit is a: [breaking-change]
2015-01-07use slicing sugarJorge Aparicio-3/+3
2015-01-07std: Stabilize the std::hash moduleAlex Crichton-3/+6
This commit aims to prepare the `std::hash` module for alpha by formalizing its current interface whileholding off on adding `#[stable]` to the new APIs. The current usage with the `HashMap` and `HashSet` types is also reconciled by separating out composable parts of the design. The primary goal of this slight redesign is to separate the concepts of a hasher's state from a hashing algorithm itself. The primary change of this commit is to separate the `Hasher` trait into a `Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was actually just a factory for various states, but hashing had very little control over how these states were used. Additionally the old `Hasher` trait was actually fairly unrelated to hashing. This commit redesigns the existing `Hasher` trait to match what the notion of a `Hasher` normally implies with the following definition: trait Hasher { type Output; fn reset(&mut self); fn finish(&self) -> Output; } This `Hasher` trait emphasizes that hashing algorithms may produce outputs other than a `u64`, so the output type is made generic. Other than that, however, very little is assumed about a particular hasher. It is left up to implementors to provide specific methods or trait implementations to feed data into a hasher. The corresponding `Hash` trait becomes: trait Hash<H: Hasher> { fn hash(&self, &mut H); } The old default of `SipState` was removed from this trait as it's not something that we're willing to stabilize until the end of time, but the type parameter is always required to implement `Hasher`. Note that the type parameter `H` remains on the trait to enable multidispatch for specialization of hashing for particular hashers. Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is simply used as part `derive` and the implementations for all primitive types. With these definitions, the old `Hasher` trait is realized as a new `HashState` trait in the `collections::hash_state` module as an unstable addition for now. The current definition looks like: trait HashState { type Hasher: Hasher; fn hasher(&self) -> Hasher; } The purpose of this trait is to emphasize that the one piece of functionality for implementors is that new instances of `Hasher` can be created. This conceptually represents the two keys from which more instances of a `SipHasher` can be created, and a `HashState` is what's stored in a `HashMap`, not a `Hasher`. Implementors of custom hash algorithms should implement the `Hasher` trait, and only hash algorithms intended for use in hash maps need to implement or worry about the `HashState` trait. The entire module and `HashState` infrastructure remains `#[unstable]` due to it being recently redesigned, but some other stability decision made for the `std::hash` module are: * The `Writer` trait remains `#[experimental]` as it's intended to be replaced with an `io::Writer` (more details soon). * The top-level `hash` function is `#[unstable]` as it is intended to be generic over the hashing algorithm instead of hardwired to `SipHasher` * The inner `sip` module is now private as its one export, `SipHasher` is reexported in the `hash` module. And finally, a few changes were made to the default parameters on `HashMap`. * The `RandomSipHasher` default type parameter was renamed to `RandomState`. This renaming emphasizes that it is not a hasher, but rather just state to generate hashers. It also moves away from the name "sip" as it may not always be implemented as `SipHasher`. This type lives in the `std::collections::hash_map` module as `#[unstable]` * The associated `Hasher` type of `RandomState` is creatively called... `Hasher`! This concrete structure lives next to `RandomState` as an implemenation of the "default hashing algorithm" used for a `HashMap`. Under the hood this is currently implemented as `SipHasher`, but it draws an explicit interface for now and allows us to modify the implementation over time if necessary. There are many breaking changes outlined above, and as a result this commit is a: [breaking-change]
2015-01-07Merge pull request #20674 from jbcrail/fix-misspelled-commentsbors-1/+1
Fix misspelled comments. Reviewed-by: steveklabnik
2015-01-06More test fixesAlex Crichton-21/+20
2015-01-06Fix misspelled comments.Joseph Crail-1/+1
I cleaned up comments prior to the 1.0 alpha release.
2015-01-06rollup merge of #20650: klutzy/omg-windows-error-modeAlex Crichton-0/+7
Believe or not, `CreateProcess()` is racy if several threads create child processes: [0], [1], [2]. This caused some tests show crash dialogs during `make check-stage#-rpass`. More explanation: On Windows, `SetErrorMode()` controls display of error dialogs: it accepts new error mode and returns old error mode. The error mode is process-global and automatically inherited to child process when created. MSYS2 bash shell internally sets it to not show error dialogs, therefore `make check-stage#-rpass` should not show them either. However, [1] says that `CreateProcess()` internally invokes `SetErrorMode()` twice: at first it sets mode `0x8001` and saves original mode, and at second it restores original mode. So if two threads simultaneously call `CreateProcess()`, the first thread sets error mode to `0x8001` then the second thread recognizes that current error mode is `0x8001`. Therefore, The second thread will create process with wrong error mode. This really occurs inside `compiletest`: it creates several processes on each thread, so some `run-pass` tests are invoked with wrong error mode therefore show crash dialog. This commit adds `StaticMutex` for `CreateProcess()` call. This seems to fix the "dialog annoyance" issue. [0]: http://support.microsoft.com/kb/315939 [1]: https://code.google.com/p/nativeclient/issues/detail?id=2968 [2]: https://ghc.haskell.org/trac/ghc/ticket/2650
2015-01-06rollup merge of #20612: retep998/winsizeAlex Crichton-7/+39
This calculates the width and height using the bounding box of the window in the buffer. Bounding box coordinates are inclusive so I have to add 1 to both dimensions.
2015-01-07falloutNick Cameron-1/+2
2015-01-07Replace full slice notation with index callsNick Cameron-2/+2
2015-01-07std: prevent `CreateProcess()` race on Windowsklutzy-0/+7
Believe or not, `CreateProcess()` is racy if several threads create child processes: [0], [1], [2]. This caused some tests show crash dialogs during `make check-stage#-rpass`. More explanation: On Windows, `SetErrorMode()` controls display of error dialogs: it accepts new error mode and returns old error mode. The error mode is process-global and automatically inherited to child process when created. MSYS2 bash shell internally sets it to not show error dialogs, therefore `make check-stage#-rpass` should not show them either. However, [1] says that `CreateProcess()` internally invokes `SetErrorMode()` twice: at first it sets mode `0x8001` and saves original mode, and at second it restores original mode. So if two threads simultaneously call `CreateProcess()`, the first thread sets error mode to `0x8001` then the second thread recognizes that current error mode is `0x8001`. Therefore, The second thread will create process with wrong error mode. This really occurs inside `compiletest`: it creates several processes on each thread, so some `run-pass` tests are invoked with wrong error mode therefore show crash dialog. This commit adds `StaticMutex` for `CreateProcess()` call. This seems to fix the "dialog annoyance" issue. [0]: http://support.microsoft.com/kb/315939 [1]: https://code.google.com/p/nativeclient/issues/detail?id=2968 [2]: https://ghc.haskell.org/trac/ghc/ticket/2650
2015-01-05More test fixes!Alex Crichton-8/+6
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 03:05:38 +0000