rust/src/libstd/sys_common, branch 1.26.1

Implement `shrink_to` method on collections

2018-03-27T00:39:11+00:00

Rollup merge of #48624 - bdrewery:freebsd-posix-spawn, r=alexcrichton

2018-03-23T17:16:07+00:00

Command: Support posix_spawn() on FreeBSD/OSX/GNU Linux

Deprecate the AsciiExt trait in favor of inherent methods

2018-03-21T16:54:33+00:00

The trait and some of its methods are stable and will remain. Some of the newer methods are unstable and can be removed later. Fixes https://github.com/rust-lang/rust/issues/39658

Simplify PATH key comparison

2018-03-19T23:15:26+00:00

Don't use posix_spawn() if PATH was modified in the environment.

2018-03-19T22:40:09+00:00

The expected behavior is that the environment's PATH should be used to find the process. posix_spawn() could be used if we iterated PATH to search for the binary to execute. For now just skip posix_spawn() if PATH is modified.

while let all the things

2018-03-05T18:58:54+00:00

fix more typos found by codespell.

2018-02-17T16:38:49+00:00

Use a range to identify SIGSEGV in stack guards

2018-01-31T19:41:29+00:00

Previously, the `guard::init()` and `guard::current()` functions were returning a `usize` address representing the top of the stack guard, respectively for the main thread and for spawned threads. The `SIGSEGV` handler on `unix` targets checked if a fault was within one page below that address, if so reporting it as a stack overflow. Now `unix` targets report a `Range` representing the guard memory, so it can cover arbitrary guard sizes. Non-`unix` targets which always return `None` for guards now do so with `Option`, so they don't pay any overhead. For `linux-gnu` in particular, the previous guard upper-bound was `stackaddr + guardsize`, as the protected memory was *inside* the stack. This was a glibc bug, and starting from 2.27 they are moving the guard *past* the end of the stack. However, there's no simple way for us to know where the guard page actually lies, so now we declare it as the whole range of `stackaddr ± guardsize`, and any fault therein will be called a stack overflow. This fixes #47863.

Print inlined functions on Windows

2018-01-26T03:49:54+00:00

Only link res_init() on GNU/*nix

2018-01-15T19:30:44+00:00

To workaround a bug in glibc <= 2.26 lookup_host() calls res_init() based on the glibc version detected at runtime. While this avoids calling res_init() on platforms where it's not required we will still end up linking against the symbol. This causes an issue on macOS where res_init() is implemented in a separate library (libresolv.9.dylib) from the main libc. While this is harmless for standalone programs it becomes a problem if Rust code is statically linked against another program. If the linked program doesn't already specify -lresolv it will cause the link to fail. This is captured in issue #46797 Fix this by hooking in to the glibc workaround in `cvt_gai` and only activating it for the "gnu" environment on Unix This should include all glibc platforms while excluding musl, windows-gnu, macOS, FreeBSD, etc. This has the side benefit of removing the #[cfg] in sys_common; only unix.rs has code related to the workaround now.