rust/src/libstd/sys_common, branch 1.44.0

Add illumos triple

2020-04-14T20:36:07+00:00

Co-Authored-By: Jason King Co-Authored-By: Joshua M. Clulow

Forward OsStr::clone_into to the inner Vec

2020-04-07T01:26:37+00:00

Despite OS differences, they're all just `Vec` inside, so we can just forward `clone_into` calls to that optimized implementation.

Inline start_thread into its callers.

2020-03-31T22:15:14+00:00

Rollup merge of #69937 - TyPR124:osstr_ascii, r=dtolnay

2020-03-29T00:32:17+00:00

ASCII methods on OsStr Would close #69566 I don't know enough about encodings to know if this is a valid change, however the comment on the issue suggests it could be. This does two things: 1. Makes ASCII methods available on OsStr 2. Makes it possible to obtain a `&mut OsStr`. This is necessary to actually use `OsStr::make_ascii_*case` methods since they modify the underlying value. As far as I can tell, the only way to modify a `&mut OsStr` is via the methods I just added. My original hope was to have these methods on `OsStrExt` for Windows, since the standard library already assumes `make_ascii_uppercase` is valid in Windows (see the change I made to windows/process.rs). If it is found these are not valid changes on non-Windows platforms, I can move the methods to the ext trait instead.

ascii methods on osstr

2020-03-28T22:34:48+00:00

Rollup merge of #70048 - TyPR124:mutable_osstr, r=dtolnay

2020-03-27T00:23:51+00:00

Allow obtaining &mut OsStr ```rust impl DerefMut for OsString {...} // type Target = OsStr impl IndexMut for OsString {...} // type Output = OsStr ``` --- This change is pulled out of #69937 per @dtolnay This implements `DerefMut for OsString` to allow obtaining a `&mut OsStr`. This also implements `IndexMut for OsString`, which is used by `DerefMut`. This pattern is the same as is used by `Deref`. This is necessary to for methods like `make_ascii_lowercase` which need to mutate the underlying value.

Rollup merge of #69955 - alexcrichton:stderr-infallible, r=sfackler

2020-03-21T12:06:38+00:00

Fix abort-on-eprintln during process shutdown This commit fixes an issue where if `eprintln!` is used in a TLS destructor it can accidentally cause the process to abort. TLS destructors are executed after `main` returns on the main thread, and at this point we've also deinitialized global `Lazy` values like those which store the `Stderr` and `Stdout` internals. This means that despite handling TLS not being accessible in `eprintln!`, we will fail due to not being able to call `stderr()`. This means that we'll double-panic quickly because panicking also attempt to write to stderr. The fix here is to reimplement the global stderr handle to avoid the need for destruction. This avoids the need for `Lazy` as well as the hidden panic inside of the `stderr` function. Overall this should improve the robustness of printing errors and/or panics in weird situations, since the `stderr` accessor should be infallible in more situations.

remove redundant returns (clippy::needless_return)

2020-03-20T19:23:03+00:00

Fix abort-on-eprintln during process shutdown

2020-03-20T14:34:56+00:00

This commit fixes an issue where if `eprintln!` is used in a TLS destructor it can accidentally cause the process to abort. TLS destructors are executed after `main` returns on the main thread, and at this point we've also deinitialized global `Lazy` values like those which store the `Stderr` and `Stdout` internals. This means that despite handling TLS not being accessible in `eprintln!`, we will fail due to not being able to call `stderr()`. This means that we'll double-panic quickly because panicking also attempt to write to stderr. The fix here is to reimplement the global stderr handle to avoid the need for destruction. This avoids the need for `Lazy` as well as the hidden panic inside of the `stderr` function. Overall this should improve the robustness of printing errors and/or panics in weird situations, since the `stderr` accessor should be infallible in more situations.

add comments about safety

2020-03-16T20:12:54+00:00