about summary refs log tree commit diff
path: root/src/libstd/sys/windows/process.rs
AgeCommit message (Collapse)AuthorLines
2016-08-24Use `#[prelude_import]` in `libstd`.Jeffrey Seyfried-3/+0
2016-05-24std: Stabilize APIs for the 1.10 releaseAlex Crichton-3/+24
This commit applies the FCP decisions made by the libs team for the 1.10 cycle, including both new stabilizations and deprecations. Specifically, the list of APIs is: Stabilized: * `os::windows::fs::OpenOptionsExt::access_mode` * `os::windows::fs::OpenOptionsExt::share_mode` * `os::windows::fs::OpenOptionsExt::custom_flags` * `os::windows::fs::OpenOptionsExt::attributes` * `os::windows::fs::OpenOptionsExt::security_qos_flags` * `os::unix::fs::OpenOptionsExt::custom_flags` * `sync::Weak::new` * `Default for sync::Weak` * `panic::set_hook` * `panic::take_hook` * `panic::PanicInfo` * `panic::PanicInfo::payload` * `panic::PanicInfo::location` * `panic::Location` * `panic::Location::file` * `panic::Location::line` * `ffi::CStr::from_bytes_with_nul` * `ffi::CStr::from_bytes_with_nul_unchecked` * `ffi::FromBytesWithNulError` * `fs::Metadata::modified` * `fs::Metadata::accessed` * `fs::Metadata::created` * `sync::atomic::Atomic{Usize,Isize,Bool,Ptr}::compare_exchange` * `sync::atomic::Atomic{Usize,Isize,Bool,Ptr}::compare_exchange_weak` * `collections::{btree,hash}_map::{Occupied,Vacant,}Entry::key` * `os::unix::net::{UnixStream, UnixListener, UnixDatagram, SocketAddr}` * `SocketAddr::is_unnamed` * `SocketAddr::as_pathname` * `UnixStream::connect` * `UnixStream::pair` * `UnixStream::try_clone` * `UnixStream::local_addr` * `UnixStream::peer_addr` * `UnixStream::set_read_timeout` * `UnixStream::set_write_timeout` * `UnixStream::read_timeout` * `UnixStream::write_Timeout` * `UnixStream::set_nonblocking` * `UnixStream::take_error` * `UnixStream::shutdown` * Read/Write/RawFd impls for `UnixStream` * `UnixListener::bind` * `UnixListener::accept` * `UnixListener::try_clone` * `UnixListener::local_addr` * `UnixListener::set_nonblocking` * `UnixListener::take_error` * `UnixListener::incoming` * RawFd impls for `UnixListener` * `UnixDatagram::bind` * `UnixDatagram::unbound` * `UnixDatagram::pair` * `UnixDatagram::connect` * `UnixDatagram::try_clone` * `UnixDatagram::local_addr` * `UnixDatagram::peer_addr` * `UnixDatagram::recv_from` * `UnixDatagram::recv` * `UnixDatagram::send_to` * `UnixDatagram::send` * `UnixDatagram::set_read_timeout` * `UnixDatagram::set_write_timeout` * `UnixDatagram::read_timeout` * `UnixDatagram::write_timeout` * `UnixDatagram::set_nonblocking` * `UnixDatagram::take_error` * `UnixDatagram::shutdown` * RawFd impls for `UnixDatagram` * `{BTree,Hash}Map::values_mut` * `<[_]>::binary_search_by_key` Deprecated: * `StaticCondvar` - this, and all other static synchronization primitives below, are usable today through the lazy-static crate on stable Rust today. Additionally, we'd like the non-static versions to be directly usable in a static context one day, so they're unlikely to be the final forms of the APIs in any case. * `CONDVAR_INIT` * `StaticMutex` * `MUTEX_INIT` * `StaticRwLock` * `RWLOCK_INIT` * `iter::Peekable::is_empty` Closes #27717 Closes #27720 cc #27784 (but encode methods still exist) Closes #30014 Closes #30425 Closes #30449 Closes #31190 Closes #31399 Closes #31767 Closes #32111 Closes #32281 Closes #32312 Closes #32551 Closes #33018
2016-04-26std: Allow creating ExitStatus from raw valuesAlex Crichton-0/+6
Sometimes a process may be waited on externally from the standard library, in which case it can be useful to create a raw `ExitStatus` structure to return. This commit extends the existing Unix `ExitStatusExt` extension trait and adds a new Windows-specific `ExitStatusExt` extension trait to do this. The methods are currently called `ExitStatus::from_raw`. cc #32713
2016-03-22fix alignmentJorge Aparicio-2/+2
2016-03-22try! -> ?Jorge Aparicio-24/+24
Automated conversion using the untry tool [1] and the following command: ``` $ find -name '*.rs' -type f | xargs untry ``` at the root of the Rust repo. [1]: https://github.com/japaric/untry
2016-03-08std: Don't always create stdin for childrenAlex Crichton-2/+4
For example if `Command::output` or `Command::status` is used then stdin is just immediately closed. Add an option for this so as an optimization we can avoid creating pipes entirely. This should help reduce the number of active file descriptors when spawning processes on Unix and the number of active handles on Windows.
2016-02-10std: Push process stdio setup in std::sysAlex Crichton-90/+135
Most of this is platform-specific anyway, and we generally have to jump through fewer hoops to do the equivalent operation on Windows. One benefit for Windows today is that this new structure avoids an extra `DuplicateHandle` when creating pipes. For Unix, however, the behavior should be the same. Note that this is just a pure refactoring, no functionality was added or removed.
2016-02-10std: Lift out Windows' CreateProcess lock a bitAlex Crichton-13/+20
The function `CreateProcess` is not itself unsafe to call from many threads, the article in question is pointing out that handles can be inherited by unintended child processes. This is basically the same race as the standard Unix open-then-set-cloexec race. Since the intention of the lock is to protect children from inheriting unintended handles, the lock is now lifted out to before the creation of the child I/O handles (which will all be inheritable). This will ensure that we only have one process in Rust at least creating inheritable handles at a time, preventing unintended inheritance to children.
2016-02-10std: Rename Stdio::None to Stdio::NullAlex Crichton-6/+5
This better reflects what it's actually doing as we don't actually have an option for "leave this I/O slot as an empty hole".
2016-02-10std: Push Child's exit status to sys::processAlex Crichton-3/+5
On Unix we have to be careful to not call `waitpid` twice, but we don't have to be careful on Windows due to the way process handles work there. As a result the cached `Option<ExitStatus>` is only necessary on Unix, and it's also just an implementation detail of the Unix module. At the same time. also update some code in `kill` on Unix to avoid a wonky waitpid with WNOHANG. This was added in 0e190b9a to solve #13124, but the `signal(0)` method is not supported any more so there's no need to for this workaround. I believe that this is no longer necessary as it's not really doing anything.
2016-02-10std: Refactor process spawning on UnixAlex Crichton-3/+0
* Build up the argp/envp pointers while the `Command` is being constructed rather than only when `spawn` is called. This will allow better sharing of code between fork/exec paths. * Rename `child_after_fork` to `exec` and have it only perform the exec half of the spawning. This also means the return type has changed to `io::Error` rather than `!` to represent errors that happen.
2016-02-03std: Properly handle interior NULs in std::processKamal Marhubi-29/+52
This reports an error at the point of calling `Command::spawn()` or one of its equivalents. Fixes https://github.com/rust-lang/rust/issues/30858 Fixes https://github.com/rust-lang/rust/issues/30862
2016-01-26Auto merge of #31120 - alexcrichton:attribute-deny-warnings, r=brsonbors-1/+0
This commit removes the `-D warnings` flag being passed through the makefiles to all crates to instead be a crate attribute. We want these attributes always applied for all our standard builds, and this is more amenable to Cargo-based builds as well. Note that all `deny(warnings)` attributes are gated with a `cfg(stage0)` attribute currently to match the same semantics we have today
2016-01-26Fix warnings during testsAlex Crichton-1/+0
The deny(warnings) attribute is now enabled for tests so we need to weed out these warnings as well.
2016-01-25std: Fix some behavior without stdio handlesAlex Crichton-3/+8
On all platforms, reading from stdin where the actual stdin isn't present should return 0 bytes as having been read rather than the entire buffer. On Windows, handle the case where we're inheriting stdio handles but one of them isn't present. Currently the behavior is to fail returning an I/O error but instead this commit corrects it to detecting this situation and propagating the non-set handle. Closes #31167
2015-11-09std: Migrate to the new libcAlex Crichton-37/+31
* Delete `sys::unix::{c, sync}` as these are now all folded into libc itself * Update all references to use `libc` as a result. * Update all references to the new flat namespace. * Moves all windows bindings into sys::c
2015-11-06std: Refactor process exit code handling slightlyAlex Crichton-13/+8
* Store the native representation directly in the `ExitStatus` structure instead of a "parsed version" (mostly for Unix). * On Windows, be more robust against processes exiting with the status of 259. Unfortunately this exit code corresponds to `STILL_ACTIVE`, causing libstd to think the process was still alive, causing an infinite loop. Instead the loop is removed altogether and `WaitForSingleObject` is used to wait for the process to exit.
2015-07-20std: Add IntoRaw{Fd,Handle,Socket} traitsAlex Crichton-0/+2
This commit is an implementation of [RFC 1174][rfc] which adds three new traits to the standard library: * `IntoRawFd` - implemented on Unix for all I/O types (files, sockets, etc) * `IntoRawHandle` - implemented on Windows for files, processes, etc * `IntoRawSocket` - implemented on Windows for networking types [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1174-into-raw-fd-socket-handle-traits.md Closes #27062
2015-06-09std: Tweak process raising/lowering implementationsAlex Crichton-17/+5
* Slate these features to be stable in 1.2 instead of 1.1 (not being backported) * Have the `FromRawFd` implementations follow the contract of the `FromRawFd` trait by taking ownership of the primitive specified. * Refactor the implementations slightly to remove the `unreachable!` blocks as well as separating the stdio representation of `std::process` from `std::sys::process`.
2015-05-29Auto merge of #25494 - alexcrichton:stdio-from-raw, r=aturonbors-1/+16
This commit implements a number of standard traits for the standard library's process I/O handles. The `FromRaw{Fd,Handle}` traits are now implemented for the `Stdio` type and the `AsRaw{Fd,Handle}` traits are now implemented for the `Child{Stdout,Stdin,Stderr}` types. The stability markers for these implementations mention that they are stable for 1.1 as I will nominate this commit for cherry-picking to beta.
2015-05-27Use `const fn` to abstract away the contents of UnsafeCell & friends.Eduard Burtescu-2/+2
2015-05-16std: Implement lowering and raising for process IOAlex Crichton-1/+16
This commit implements a number of standard traits for the standard library's process I/O handles. The `FromRaw{Fd,Handle}` traits are now implemented for the `Stdio` type and the `AsRaw{Fd,Handle}` traits are now implemented for the `Child{Stdout,Stdin,Stderr}` types. Additionally this implements the `AsRawHandle` trait for `Child` on Windows. The stability markers for these implementations mention that they are stable for 1.1 as I will nominate this commit for cherry-picking to beta.
2015-05-16std: Add an unstable method Child::idAlex Crichton-0/+6
This commits adds a method to the `std::process` module to get the process identifier of the child as a `u32`. On Windows the underlying identifier is already a `u32`, and on Unix the type is typically defined as `c_int` (`i32` for almost all our supported platforms), but the actually pid is normally a small positive number. Eventually we may add functions to load information about a process based on its identifier or the ability to terminate a process based on its identifier, but for now this function should enable this sort of functionality to exist outside the standard library.
2015-05-07std: Rename sys::foo2 modules to sys::fooAlex Crichton-0/+429
Now that `std::old_io` has been removed for quite some time the naming real estate here has opened up to allow these modules to move back to their proper names.
2015-04-14std: Remove old_io/old_path/rand modulesAlex Crichton-518/+0
This commit entirely removes the old I/O, path, and rand modules. All functionality has been deprecated and unstable for quite some time now!
2015-04-01Test fixes and rebase conflictsAlex Crichton-2/+2
2015-03-31Test fixes and rebase conflicts, round 2Alex Crichton-1/+0
2015-03-31std: Clean out #[deprecated] APIsAlex Crichton-5/+11
This commit cleans out a large amount of deprecated APIs from the standard library and some of the facade crates as well, updating all users in the compiler and in tests as it goes along.
2015-03-26Mass rename uint/int to usize/isizeAlex Crichton-5/+5
Now that support has been removed, all lingering use cases are renamed.
2015-03-20std: Remove old_io/old_path from the preludeAlex Crichton-1/+1
This commit removes the reexports of `old_io` traits as well as `old_path` types and traits from the prelude. This functionality is now all deprecated and needs to be removed to make way for other functionality like `Seek` in the `std::io` module (currently reexported as `NewSeek` in the io prelude). Closes #23377 Closes #23378
2015-03-13Auto merge of #23229 - aturon:stab-path, r=alexcrichtonbors-1/+1
This commit stabilizes essentially all of the new `std::path` API. The API itself is changed in a couple of ways (which brings it in closer alignment with the RFC): * `.` components are now normalized away, unless they appear at the start of a path. This in turn effects the semantics of e.g. asking for the file name of `foo/` or `foo/.`, both of which yield `Some("foo")` now. This semantics is what the original RFC specified, and is also desirable given early experience rolling out the new API. * The `parent` method is now `without_file` and succeeds if, and only if, `file_name` is `Some(_)`. That means, in particular, that it fails for a path like `foo/../`. This change affects `pop` as well. In addition, the `old_path` module is now deprecated. [breaking-change] r? @alexcrichton
2015-03-12Stabilize std::pathAaron Turon-1/+1
This commit stabilizes essentially all of the new `std::path` API. The API itself is changed in a couple of ways (which brings it in closer alignment with the RFC): * `.` components are now normalized away, unless they appear at the start of a path. This in turn effects the semantics of e.g. asking for the file name of `foo/` or `foo/.`, both of which yield `Some("foo")` now. This semantics is what the original RFC specified, and is also desirable given early experience rolling out the new API. * The `parent` function now succeeds if, and only if, the path has at least one non-root/prefix component. This change affects `pop` as well. * The `Prefix` component now involves a separate `PrefixComponent` struct, to better allow for keeping both parsed and unparsed prefix data. In addition, the `old_path` module is now deprecated. Closes #23264 [breaking-change]
2015-03-12std: Remove #[allow] directives in sys modulesAlex Crichton-3/+0
These were suppressing lots of interesting warnings! Turns out there was also quite a bit of dead code.
2015-03-05std: Deprecate the old_io::process moduleAlex Crichton-0/+2
This module is now superseded by the `std::process` module. This module still has some room to expand to get quite back up to parity with the `old_io` version, and there is a [tracking issue][issue] for feature requests as well as known room for expansion. [issue]: https://github.com/rust-lang/rfcs/issues/941 [breaking-change]
2015-03-04std: Deprecate std::old_io::fsAlex Crichton-1/+1
This commit deprecates the majority of std::old_io::fs in favor of std::fs and its new functionality. Some functions remain non-deprecated but are now behind a feature gate called `old_fs`. These functions will be deprecated once suitable replacements have been implemented. The compiler has been migrated to new `std::fs` and `std::path` APIs where appropriate as part of this change.
2015-02-20Register new snapshotsAlex Crichton-194/+0
2015-02-19Round 5 test fixes and rebase conflictsAlex Crichton-0/+29
2015-02-18Round 4 test fixes and rebase conflictsAlex Crichton-1/+165
2015-02-18Remove `i`, `is`, `u`, or `us` suffixes that are not necessary.Niko Matsakis-1/+1
2015-02-05cleanup: replace `as[_mut]_slice()` calls with deref coercionsJorge Aparicio-5/+4
2015-02-04remove all kind annotations from closuresJorge Aparicio-1/+1
2015-02-03Rename std::path to std::old_pathAaron Turon-1/+1
As part of [RFC 474](https://github.com/rust-lang/rfcs/pull/474), this commit renames `std::path` to `std::old_path`, leaving the existing path API in place to ease migration to the new one. Updating should be as simple as adjusting imports, and the prelude still maps to the old path APIs for now. [breaking-change]
2015-02-02rollup merge of #21830: japaric/for-cleanupAlex Crichton-4/+4
Conflicts: src/librustc/metadata/filesearch.rs src/librustc_back/target/mod.rs src/libstd/os.rs src/libstd/sys/windows/os.rs src/libsyntax/ext/tt/macro_parser.rs src/libsyntax/print/pprust.rs src/test/compile-fail/issue-2149.rs
2015-02-02`for x in xs.into_iter()` -> `for x in xs`Jorge Aparicio-1/+1
Also `for x in option.into_iter()` -> `if let Some(x) = option`
2015-02-02`for x in xs.iter()` -> `for x in &xs`Jorge Aparicio-3/+3
2015-02-01std: Add a new `env` moduleAlex Crichton-12/+12
This is an implementation of [RFC 578][rfc] which adds a new `std::env` module to replace most of the functionality in the current `std::os` module. More details can be found in the RFC itself, but as a summary the following methods have all been deprecated: [rfc]: https://github.com/rust-lang/rfcs/pull/578 * `os::args_as_bytes` => `env::args` * `os::args` => `env::args` * `os::consts` => `env::consts` * `os::dll_filename` => no replacement, use `env::consts` directly * `os::page_size` => `env::page_size` * `os::make_absolute` => use `env::current_dir` + `join` instead * `os::getcwd` => `env::current_dir` * `os::change_dir` => `env::set_current_dir` * `os::homedir` => `env::home_dir` * `os::tmpdir` => `env::temp_dir` * `os::join_paths` => `env::join_paths` * `os::split_paths` => `env::split_paths` * `os::self_exe_name` => `env::current_exe` * `os::self_exe_path` => use `env::current_exe` + `pop` * `os::set_exit_status` => `env::set_exit_status` * `os::get_exit_status` => `env::get_exit_status` * `os::env` => `env::vars` * `os::env_as_bytes` => `env::vars` * `os::getenv` => `env::var` or `env::var_string` * `os::getenv_as_bytes` => `env::var` * `os::setenv` => `env::set_var` * `os::unsetenv` => `env::remove_var` Many function signatures have also been tweaked for various purposes, but the main changes were: * `Vec`-returning APIs now all return iterators instead * All APIs are now centered around `OsString` instead of `Vec<u8>` or `String`. There is currently on convenience API, `env::var_string`, which can be used to get the value of an environment variable as a unicode `String`. All old APIs are `#[deprecated]` in-place and will remain for some time to allow for migrations. The semantics of the APIs have been tweaked slightly with regard to dealing with invalid unicode (panic instead of replacement). The new `std::env` module is all contained within the `env` feature, so crates must add the following to access the new APIs: #![feature(env)] [breaking-change]
2015-01-29convert remaining `range(a, b)` to `a..b`Jorge Aparicio-1/+1
2015-01-26std: Rename Writer::write to Writer::write_allAlex Crichton-7/+7
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-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-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
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-23 20:13:36 +0000