| Age | Commit message (Collapse) | Author | Lines |
|---|
|
NetBSD: link libstd with librt in addition to libpthread
Some aio(3) and mq(3) functions in the libc crate actually come from NetBSD librt, not libc or libpthread.
|
|
Add BufWriter::buffer method
CC #45323
|
|
Redox: Update to new changes
These are all cherry-picked from our fork:
- Remove the `env:` scheme
- Update `execve` system call to `fexec`
- Interpret shebangs: these are no longer handled by the kernel, which like usual tries to be as minimal as possible
|
|
This commit, after reverting #55359, applies a different fix for #46775
while also fixing #55775. The basic idea was to go back to pre-#55359
libstd, and then fix #46775 in a way that doesn't expose #55775.
The issue described in #46775 boils down to two problems:
* First, the global environment is reset during `exec` but, but if the
`exec` call fails then the global environment was a dangling pointer
into free'd memory as the block of memory was deallocated when
`Command` is dropped. This is fixed in this commit by installing a
`Drop` stack object which ensures that the `environ` pointer is
preserved on a failing `exec`.
* Second, the global environment was accessed in an unsynchronized
fashion during `exec`. This was fixed by ensuring that the
Rust-specific environment lock is acquired for these system-level
operations.
Thanks to Alex Gaynor for pioneering the solution here!
Closes #55775
Co-authored-by: Alex Gaynor <alex.gaynor@gmail.com>
|
|
This reverts commit 36fe3b605a7a7143a14565272140ba1b43c1b041.
|
|
|
|
global allocators: add a few comments
These comments answer some questions that came up when I tried to understand how the control flow works for the global allocator, `Global` and `System`.
r? @alexcrichton
|
|
Fix a typo in std::panic
|
|
|
|
Avoid converting bytes to UTF-8 strings to print, just pass bytes to stdout/err
r? @nikomatsakis
|
|
Minor standard library constification
This PR makes some bits of the standard library into `const fn`s.
I've tried to be as aggressive as I possibly could in the constification.
The list is rather small due to how restrictive `const fn` is at the moment.
r? @oli-obk cc @rust-lang/libs
Stable public APIs affected:
+ [x] `Cell::as_ptr`
+ [x] `UnsafeCell::get`
+ [x] `char::is_ascii`
+ [x] `iter::empty`
+ [x] `ManuallyDrop::{new, into_inner}`
+ [x] `RangeInclusive::{start, end}`
+ [x] `NonNull::as_ptr`
+ [x] `{[T], str}::as_ptr`
+ [x] `Duration::{as_secs, subsec_millis, subsec_micros, subsec_nanos}`
+ [x] `CStr::as_ptr`
+ [x] `Ipv4Addr::is_unspecified`
+ [x] `Ipv6Addr::new`
+ [x] `Ipv6Addr::octets`
Unstable public APIs affected:
+ [x] `Duration::{as_millis, as_micros, as_nanos, as_float_secs}`
+ [x] `Wrapping::{count_ones, count_zeros, trailing_zeros, rotate_left, rotate_right, swap_bytes, reverse_bits, from_be, from_le, to_be, to_le, leading_zeros, is_positive, is_negative, leading_zeros}`
+ [x] `core::convert::identity`
--------------------------
## Removed from list in first pass:
Stable public APIs affected:
+ [ ] `BTree{Map, Set}::{len, is_empty}`
+ [ ] `VecDeque::is_empty`
+ [ ] `String::{is_empty, len}`
+ [ ] `FromUtf8Error::utf8_error`
+ [ ] `Vec<T>::{is_empty, len}`
+ [ ] `Layout::size`
+ [ ] `DecodeUtf16Error::unpaired_surrogate`
+ [ ] `core::fmt::{fill, width, precision, sign_plus, sign_minus, alternate, sign_aware_zero_pad}`
+ [ ] `panic::Location::{file, line, column}`
+ [ ] `{ChunksExact, RChunksExact}::remainder`
+ [ ] `Utf8Error::valid_up_to`
+ [ ] `VacantEntry::key`
+ [ ] `NulError::nul_position`
+ [ ] `IntoStringError::utf8_error`
+ [ ] `IntoInnerError::error`
+ [ ] `io::Chain::get_ref`
+ [ ] `io::Take::{limit, get_ref}`
+ [ ] `SocketAddrV6::{flowinfo, scope_id}`
+ [ ] `PrefixComponent::{kind, as_os_str}`
+ [ ] `Path::{ancestors, display}`
+ [ ] `WaitTimeoutResult::timed_out`
+ [ ] `Receiver::{iter, try_iter}`
+ [ ] `thread::JoinHandle::thread`
+ [ ] `SystemTimeError::duration`
Unstable public APIs affected:
+ [ ] `core::fmt::Arguments::new_v1`
+ [ ] `core::fmt::Arguments::new_v1_formatted`
+ [ ] `Pin::{get_ref, into_ref}`
+ [ ] `Utf8Lossy::chunks`
+ [ ] `LocalWaker::as_waker`
+ [ ] `panic::PanicInfo::{internal_constructor, message, location}`
+ [ ] `panic::Location::{internal_constructor }`
## Removed from list in 2nd pass:
Stable public APIs affected:
+ [ ] `LinkedList::{new, iter, is_empty, len}`
+ [ ] `mem::forget`
+ [ ] `Cursor::{new, get_ref, position}`
+ [ ] `io::{empty, repeat, sink}`
+ [ ] `PoisonError::new`
+ [ ] `thread::Builder::new`
+ [ ] `process::Stdio::{piped, inherit, null}`
Unstable public APIs affected:
+ [ ] `io::Initializer::{zeroing, should_initialize}`
|
|
|
|
This commit deletes the `alloc_system` crate from the standard
distribution. This unstable crate is no longer needed in the modern
stable global allocator world, but rather its functionality is folded
directly into the standard library. The standard library was already the
only stable location to access this crate, and as a result this should
not affect any stable code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previous version does not show that or_insert does not insert the
passed value, as the passed value was the same value as what was
already in the map.
|
|
Add tracking issue for Layout methods (and some API changes)
These methods are already useful when used with the stable global allocator API (stabilized in #51241).
```rust
pub fn align_to(&self, align: usize) -> Result<Layout, LayoutErr>;
pub fn padding_needed_for(&self, align: usize) -> usize;
pub fn repeat(&self, n: usize) -> Result<(Layout, usize), LayoutErr>;
pub fn extend(&self, next: Layout) -> Result<(Layout, usize), LayoutErr>;
pub fn repeat_packed(&self, n: usize) -> Result<Layout, LayoutErr>;
pub fn extend_packed(&self, next: Layout) -> Result<Layout, LayoutErr>;
pub fn array<T>(n: usize) -> Result<Layout, LayoutErr>;
```
cc #32838
r? @SimonSapin
|
|
refactor: use shorthand fields
refactor: use shorthand for single fields everywhere (excluding tests).
|
|
|
|
|
|
Add precision for create_dir function
Took me a while to find the other equivalent so it seems to be necessary.
r? @QuietMisdreavus
|
|
std: Enable usage of `thread_local!` through imports
The `thread_local!` macro delegated to an internal macro but it didn't
do so in a macros-and-the-module-system compatible fashion, meaning if a
`#![no_std]` crate imported `std` and tried to use `thread_local!` it
would fail due to missing a lookup of an internal macro.
This commit switches the macro to instead use `$crate` to invoke other
macros, ensuring that it'll work when `thread_local!` is imported alone.
|
|
std: Improve codegen size of accessing TLS
Some code in the TLS implementation in libstd stores `Some(val)` into an
`&mut Option<T>` (effectively) and then pulls out `&T`, but it currently
uses `.unwrap()` which can codegen into a panic even though it can never
panic. With sufficient optimizations enabled (like LTO) the compiler can
see through this but this commit helps it along in normal mode
(`--release` with Cargo by default) to avoid codegen'ing the panic path.
This ends up improving the optimized codegen on wasm by ensuring that a
call to panic pulling in more file size doesn't stick around.
|
|
Correct alignment of atomic types and (re)add Atomic{I,U}128
This is a updated https://github.com/rust-lang/rust/pull/53514 to also make atomic types `repr(C)` as per comment in https://github.com/rust-lang/rust/pull/53514#issuecomment-431042767.
Fixes #39590
Closes #53514
r? @pnkfelix
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This commit removes all jemalloc related submodules, configuration, etc,
from the bootstrap, from the standard library, and from the compiler.
This will be followed up with a change to use jemalloc specifically as
part of rustc on blessed platforms.
|
|
Add raw_entry API to HashMap
This is a continuation of #50821.
|
|
Fixes #46775 -- don't mutate the process's environment in Command::exec
Instead, pass the environment to execvpe, so the kernel can apply it directly to the new process. This avoids a use-after-free in the case where exec'ing the new process fails for any reason, as well as a race condition if there are other threads alive during the exec.
Fixes #46775
|
|
The `thread_local!` macro delegated to an internal macro but it didn't
do so in a macros-and-the-module-system compatible fashion, meaning if a
`#![no_std]` crate imported `std` and tried to use `thread_local!` it
would fail due to missing a lookup of an internal macro.
This commit switches the macro to instead use `$crate` to invoke other
macros, ensuring that it'll work when `thread_local!` is imported alone.
|
|
Some code in the TLS implementation in libstd stores `Some(val)` into an
`&mut Option<T>` (effectively) and then pulls out `&T`, but it currently
uses `.unwrap()` which can codegen into a panic even though it can never
panic. With sufficient optimizations enabled (like LTO) the compiler can
see through this but this commit helps it along in normal mode
(`--release` with Cargo by default) to avoid codegen'ing the panic path.
This ends up improving the optimized codegen on wasm by ensuring that a
call to panic pulling in more file size doesn't stick around.
|
|
Instead, pass the environment to execvpe, so the kernel can apply it directly to the new process. This avoids a use-after-free in the case where exec'ing the new process fails for any reason, as well as a race condition if there are other threads alive during the exec.
|
|
|
|
* Also update the bootstrap compiler
* Update cargo to 1.32.0
* Clean out stage0 annotations
|
|
This means when the other thread wakes it can continue right away
instead of having to wait for the mutex.
Also add some comments explaining why the mutex needs to be locked in
the first place.
|
|
|
|
Unchecked thread spawning
# Summary
Add an unsafe interface for spawning lifetime-unrestricted threads for
library authors to build less-contrived, less-hacky safe abstractions
on.
# Motivation
So a few years back scoped threads were entirely removed from the Rust
stdlib, the reason being that it was possible to leak the scoped thread's
join guards without resorting to unsafe code, which meant the concept
was not completely safe, either.
Only a maximally-restrictive safe API for thread spawning was kept in the
stdlib, that requires `'static` lifetime bounds on both the thread closure
and its return type.
A number of 3rd party libraries sprung up to offer their implementations
for safe scoped threads implementations.
These work by essentially hiding the join guards from the user, thus
forcing them to join at the end of an (internal) function scope.
However, since these libraries have to use the maximally restrictive
thread spawning API, they have to resort to some very contrived manipulations
and subversions of Rust's type system to basically achieve what this commit does
with some minimal restructuring of the current code and exposing a new unsafe
function signature for spawning threads without lifetime restrictions.
Obviously this is unsafe, but its main use would be to allow library authors
to write safe abstractions with and around it.
To further illustrate my point, here's a quick summary of the hoops that,
for instance `crossbeam`, has to jump through to spawn a lifetime unrestricted
thread, all of which would not be necessary if an unsafe API existed as part
of the stdlib:
1. Allocate an `Arc<Option<T>>` on the heap where the result with type
`T: 'a` will go (in practice requires `Mutex` or `UnsafeCell` as well).
2. Wrap the desired thread closure with lifetime bound `'a` into another
closure (also `..: 'a`) that returns `()`, executes the inner closure and
writes its result into the pre-allocated `Option<T>`.
3. Box the wrapping closure, cast it to a trait object (`FnBox`) and
(unsafely) transmute its lifetime bound from `'a` to `'static`.
So while this new `spawn_unchecked` function is certainly not very relevant
for general use, since scoped threads are so common I think it makes sense
to expose an interface for libraries implementing these to build on.
The changes implemented are also very minimal: The current `spawn` function
(which internally contains unsafe code) is moved into an unsafe `spawn_unchecked`
function, which the safe function then wraps around.
# Issues
- ~~so far, no documentation for the new function (yet)~~
- the name of the function might be controversial, as `*_unchecked` more commonly
indicates that some sort of runtime check is omitted (`unrestricted` may be
more fitting)
- if accepted, it might make sense to add a freestanding `thread::spawn_unchecked`
function similar to the current `thread::spawn` for convenience.
|
