| Age | Commit message (Collapse) | Author | Lines |
|---|
|
libstd: remove some mutable statics in sys::unix
My understanding is that this achieves the same behavior and performance with safe code.
|
|
|
|
|
|
Also, run RustFmt on the clashing_extern_fn test case and update
stderrs.
|
|
|
|
Add a lint to catch clashing `extern` fn declarations.
Closes #69390.
Adds lint `clashing_extern_decl` to detect when, within a single crate, an extern function of the same name is declared with different types. Because two symbols of the same name cannot be resolved to two different functions at link time, and one function cannot possibly have two types, a clashing extern declaration is almost certainly a mistake.
This lint does not run between crates because a project may have dependencies which both rely on the same extern function, but declare it in a different (but valid) way. For example, they may both declare an opaque type for one or more of the arguments (which would end up distinct types), or use types that are valid conversions in the language the extern fn is defined in. In these cases, we can't say that the clashing declaration is incorrect.
r? @eddyb
|
|
RISC-V Emulated Testing
Adds a disabled docker image on which to run RISC-V tests. Based on the armhf image.
Test using
```
./src/ci/docker/run.sh riscv64gc-linux
```
cc: @msizanoen1
|
|
This lint checks that all declarations for extern fns of the same name
are declared with the same types.
|
|
|
|
|
|
|
|
Implement `Sync` for `process::Command on unix and vxworks
Closes #72387.
r? @cuviper
|
|
|
|
Stabilize process_set_argv0 feature for Unix
This stabilizes process_set_argv0 targeting 1.45.0. It has been
useful in practice and seems useful as-is.
The equivalent feature could be implemented for Windows, but as far as I
know nobody has. That can be done separately.
Tracking issue: #66510
|
|
|
|
This stabilizes process_set_argv0 targeting 1.45.0. It has been
useful in practice and seems useful as-is.
The equivalent feature could be implemented for Windows, but as far as I
know nobody has. That can be done separately.
Tracking issue: #66510
|
|
Allow a few warnings.
On Windows, these types were causing warnings to be emitted during the
build. These types are allowed to not have idiomatic names, so the
warning should be supressed.
|
|
On Windows, these types were causing warnings to be emitted during the
build. These types are allowed to not have idiomatic names, so the
warning should be supressed.
|
|
explain the types used in the open64 call
Fixes https://github.com/rust-lang/rust/issues/71915, where I learned about this quirk. I don't actually know what I am talking about here. ;)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When working with an arbitrary reader or writer, code that uses vectored
operations may end up being slower than code that copies into a single
buffer when the underlying reader or writer doesn't actually support
vectored operations. These new methods allow you to ask the reader or
witer up front if vectored operations are efficiently supported.
Currently, you have to use some heuristics to guess by e.g. checking if
the read or write only accessed the first buffer. Hyper is one concrete
example of a library that has to do this dynamically:
https://github.com/hyperium/hyper/blob/0eaf304644a396895a4ce1f0146e596640bb666a/src/proto/h1/io.rs#L582-L594
|
|
The ioctl(FIONBIO) method of setting a file descriptor to be
non-blocking does not notify the underlying resource in the same way
that fcntl(F_SETFL, O_NONBLOCK) does on illumos and Solaris.
|
|
Co-Authored-By: Jason King <jason.brian.king@gmail.com>
Co-Authored-By: Joshua M. Clulow <jmc@oxide.computer>
|
|
Fix double-free and undefined behaviour in libstd::syn::unix::Thread::new
While working on concurrency support for Miri, I found that the `libstd::syn::unix::Thread::new` method has two potential problems: double-free and undefined behaviour.
**Double-free** could occur if the following events happened (credit for pointing this out goes to @RalfJung):
1. The call to `pthread_create` successfully launched a new thread that executed to completion and deallocated `p`.
2. The call to `pthread_attr_destroy` returned a non-zero value causing the `assert_eq!` to panic.
3. Since `mem::forget(p)` was not yet executed, the destructor of `p` would be executed and cause a double-free.
As far as I understand, this code also violates the stacked-borrows aliasing rules and thus would result in **undefined behaviour** if these rules were adopted. The problem is that the ownership of `p` is passed to the newly created thread before the call to `mem::forget`. Since the call to `mem::forget` is still a call, it counts as a use of `p` and triggers UB.
This pull request changes the code to use `mem::ManuallyDrop` instead of `mem::forget`. As a consequence, in case of a panic, `p` would be potentially leaked, which while undesirable is probably better than double-free or undefined behaviour.
|
|
|
|
|
|
|
|
|
|
use is_empty() instead of len comparison (clippy::len_zero)
use if let instead of while let loop that never loops (clippy::never_loop)
remove redundant returns (clippy::needless_return)
remove redundant closures (clippy::redundant_closure)
use if let instead of match and wildcard pattern (clippy::single_match)
don't repeat field names redundantly (clippy::redundant_field_names)
|
|
Use getentropy(2) on macos
resolves #70179
|
|
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.
|
|
|
|
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.
|
|
unix: Set a guard page at the end of signal stacks
This mitigates possible issues when signal stacks overflow, which could
manifest as segfaults or in unlucky circumstances possible clobbering of
other memory values as stack overflows tend to enable.
I went ahead and made a PR for this because it's a pretty small change, though if I should open an issue/RFC for this and discuss there first I'll happily do so. I've also added some example programs that demonstrate the uncomfortably clobber-happy behavior we currently have, and the segfaults that could/should result instead, [here](https://github.com/iximeow/jubilant-train).
|
|
Implement `Copy` for `IoSlice`
Resolves #69395
r? @sfackler
|
|
|
|
also unmap the whole thing when cleaning up, rather than leaving a spare
page floating around.
|
|
This mitigates possible issues when signal stacks overflow, which could
manifest as segfaults or in unlucky circumstances possible clobbering of
other memory values as stack overflows tend to enable.
|
|
Although `stack_overflow::init` runs very early in the process, even
before `main`, there may already be signal handlers installed for things
like the address sanitizer. In that case, just leave it alone, and don't
bother trying to allocate our own signal stacks either.
|
|
|
|
it. (clippy::redundant_static_lifetimes)
|
|
|
|
example:
let s: String = format!("hello").into();
|
|
|
