| Age | Commit message (Collapse) | Author | Lines |
|
Rollup of 12 pull requests
- Successful merges: #49243, #49329, #49364, #49400, #49405, #49427, #49428, #49429, #49439, #49442, #49444, #49452
- Failed merges:
|
|
r=GuillaumeGomez
Remove hidden `foo` functions from doc examples; use `Termination` trait.
Fixes https://github.com/rust-lang/rust/issues/49233.
Easier to review with the white-space ignoring `?w=1` feature: https://github.com/rust-lang/rust/pull/49357/files?w=1
|
|
Implement `shrink_to` method on collections
Fixes #49385
|
|
Fixes https://github.com/rust-lang/rust/issues/49233.
|
|
|
|
Reduce scope of unsafe block in sun_path_offset
I reduced the scope of the unsafe block to the `uninitialized` call which is the only actual unsafe bit.
|
|
|
|
|
|
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.
|
|
|
|
Better docs and associated SUCCESS/FAILURE for process::ExitCode
Follow-up to https://github.com/rust-lang/rust/pull/48497#discussion_r170676525, since that PR was the minimal thing to unblock https://github.com/rust-lang/rust/issues/48453#issuecomment-368155082.
r? @nikomatsakis
|
|
Now begins the saga of fixing compilation errors on other platforms...
|
|
r=sfackler
Fixes #47311.
r? @nrc
|
|
The relevant support was added in https://sourceware.org/bugzilla/show_bug.cgi?id=10354#c12
|
|
|
|
|
|
|
|
|
|
|
|
spawn() is expected to return an error if the specified file could not be
executed. FreeBSD's posix_spawn() supports returning ENOENT/ENOEXEC if
the exec() fails, which not all platforms support. This brings a very
significant performance improvement for FreeBSD, involving heavy use of
Command in threads, due to fork() invoking jemalloc fork handlers and
causing lock contention. FreeBSD's posix_spawn() avoids this problem
due to using vfork() internally.
|
|
|
|
|
|
|
|
|
|
|
|
Add tests ensuring zero-Duration timeouts result in errors; fix Redox issues.
Part of #48311
|
|
Documentation fix side of https://github.com/rust-lang/rust/issues/48311.
|
|
Part of https://github.com/rust-lang/rust/issues/48311
|
|
|
|
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<usize>` 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.
|
|
implement Send for process::Command on unix
closes https://github.com/rust-lang/rust/issues/47751
|
|
Implementing Send for a specific field rather than the whole struct is
safer: if a field is changed/modified and becomes non-Send, we can catch
it.
|
|
|
|
closes https://github.com/rust-lang/rust/issues/47751
|
|
Only link res_init() on GNU/*nix
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.
Before this commit:
```shell
> cat main.rs
use std::net::ToSocketAddrs;
#[no_mangle]
pub extern "C" fn resolve_test() -> () {
let addr_list = ("google.com.au", 0).to_socket_addrs().unwrap();
println!("{:?}", addr_list);
}
> rustc --crate-type=staticlib main.rs
> clang libmain.a test.c -o combined
Undefined symbols for architecture x86_64:
"_res_9_init", referenced from:
std::net::lookup_host::h93c17fe9ad38464a in libmain.a(std-826c8d3b356e180c.std0.rcgu.o)
ld: symbol(s) not found for architecture x86_64
clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation)
```
Afterwards:
```shell
> rustc --crate-type=staticlib main.rs
> clang libmain.a test.c -o combined
> ./combined
IntoIter([V4(172.217.25.131:0)])
```
Fixes #46797
|
|
Resolves #46137.
|
|
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.
|
|
|
|
Use memchr to speed up [u8]::contains 3x
None
|
|
Convert warning about `*const _` to a future-compat lint
#46664 was merged before I could convert the soft warning about method lookup on `*const _` into a future-compatibility lint. This PR makes that change.
fixes #46837
tracking issue for the future-compatibility lint: #46906
r? @arielb1
|
|
Capture `Command` environment at spawn
Fixes #28975
This tracks a set of changes to the environment and then replays them at spawn time.
|
|
|
|
|
|
Closes #46670.
|
|
|
|
|
|
|
|
Use the CTL_KERN.KERN_PROC_ARGS.-1.KERN_PROC_PATHNAME sysctl in
preference over the /proc/curproc/exe symlink.
Additionally, perform more validation of aformentioned symlink.
Particularly on pre-8.x NetBSD this symlink will point to '/' when
accurate information is unavailable.
|
|
Provides the following conversion implementations:
* `From<`{`CString`,`&CStr`}`>` for {`Arc`,`Rc`}`<CStr>`
* `From<`{`OsString`,`&OsStr`}`>` for {`Arc`,`Rc`}`<OsStr>`
* `From<`{`PathBuf`,`&Path`}`>` for {`Arc`,`Rc`}`<Path>`
|
|
I have this as a Unix-only API since it seems like Windows doesn't have
a similar API.
|