| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Ever since we added a Cargo-based build system for the compiler the
standard library has always been a little special, it's never been able
to depend on crates.io crates for runtime dependencies. This has been a
result of various limitations, namely that Cargo doesn't understand that
crates from crates.io depend on libcore, so Cargo tries to build crates
before libcore is finished.
I had an idea this afternoon, however, which lifts the strategy
from #52919 to directly depend on crates.io crates from the standard
library. After all is said and done this removes a whopping three
submodules that we need to manage!
The basic idea here is that for any crate `std` depends on it adds an
*optional* dependency on an empty crate on crates.io, in this case named
`rustc-std-workspace-core`. This crate is overridden via `[patch]` in
this repository to point to a local crate we write, and *that* has a
`path` dependency on libcore.
Note that all `no_std` crates also depend on `compiler_builtins`, but if
we're not using submodules we can publish `compiler_builtins` to
crates.io and all crates can depend on it anyway! The basic strategy
then looks like:
* The standard library (or some transitive dep) decides to depend on a
crate `foo`.
* The standard library adds
```toml
[dependencies]
foo = { version = "0.1", features = ['rustc-dep-of-std'] }
```
* The crate `foo` has an optional dependency on `rustc-std-workspace-core`
* The crate `foo` has an optional dependency on `compiler_builtins`
* The crate `foo` has a feature `rustc-dep-of-std` which activates these
crates and any other necessary infrastructure in the crate.
A sample commit for `dlmalloc` [turns out to be quite simple][commit].
After that all `no_std` crates should largely build "as is" and still be
publishable on crates.io! Notably they should be able to continue to use
stable Rust if necessary, since the `rename-dependency` feature of Cargo
is soon stabilizing.
As a proof of concept, this commit removes the `dlmalloc`,
`libcompiler_builtins`, and `libc` submodules from this repository. Long
thorns in our side these are now gone for good and we can directly
depend on crates.io! It's hoped that in the long term we can bring in
other crates as necessary, but for now this is largely intended to
simply make it easier to manage these crates and remove submodules.
This should be a transparent non-breaking change for all users, but one
possible stickler is that this almost for sure breaks out-of-tree
`std`-building tools like `xargo` and `cargo-xbuild`. I think it should
be relatively easy to get them working, however, as all that's needed is
an entry in the `[patch]` section used to build the standard library.
Hopefully we can work with these tools to solve this problem!
[commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #56000 (Add Armv8-M Mainline targets)
- #56250 (Introduce ptr::hash for references)
- #56434 (Improve query cycle errors for parallel queries)
- #56516 (Replace usages of `..i + 1` ranges with `..=i`.)
- #56555 (Send textual profile data to stderr, not stdout)
- #56561 (Fix bug in from_key_hashed_nocheck)
- #56574 (Fix a stutter in the docs for slice::exact_chunks)
Failed merges:
r? @ghost
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The files src/libstd/sys/sgx/*.rs are mostly copied/adapted from
the wasm target.
This also updates the dlmalloc submodule to the very latest version.
|
|
Replace usages of `..i + 1` ranges with `..=i`.
Before this change we were using old computer code techniques. After this change we use the new and improved computer code techniques.
|
|
|
|
|
|
|
|
|
|
Avoid extra copy and syscall in std::env::current_exe
|
|
cleanup: remove static lifetimes from consts in libstd
|
|
Utilize `?` instead of `return None`.
None
|
|
|
|
|
|
|
|
|
|
Remove some uses of try!
|
|
Deal with EINTR in net timeout tests
We've seen sporadic QE failures in the timeout tests on this assertion:
assert!(kind == ErrorKind::WouldBlock || kind == ErrorKind::TimedOut);
So there's an error, but not either of the expected kinds. Adding a
format to show the kind revealed `ErrorKind::Interrupted` (`EINTR`).
For the cases that were using `read`, we can just use `read_exact` to
keep trying after interruption. For those using `recv_from`, we have to
manually loop until we get a non-interrupted result.
|
|
use MaybeUninit instead of mem::uninitialized for Windows Mutex
I hope this builds, I do not have a Windows machine to test...
|
|
|
|
|
|
We've seen sporadic QE failures in the timeout tests on this assertion:
assert!(kind == ErrorKind::WouldBlock || kind == ErrorKind::TimedOut);
So there's an error, but not either of the expected kinds. Adding a
format to show the kind revealed `ErrorKind::Interrupted` (`EINTR`).
For the cases that were using `read`, we can just use `read_exact` to
keep trying after interruption. For those using `recv_from`, we have to
manually loop until we get a non-interrupted result.
|
|
Make std::os::unix/linux::fs::MetadataExt::a/m/ctime* documentation clearer
I was confused by this API so I clarified what they are doing.
I was wondering if I should try to unify more documentation and examples between `unix` and `linux` (e.g. “of the file” is used in `unix` to refer to the file these metadata is for, “of this file” in `linux`, “of the underlying file” in `std::fs::File`).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Implement checked_add_duration for SystemTime
[Original discussion on the rust user forum](https://users.rust-lang.org/t/std-systemtime-misses-a-checked-add-function/21785)
Since `SystemTime` is opaque there is no way to check if the result of an addition will be in bounds. That makes the `Add<Duration>` trait completely unusable with untrusted data. This is a big problem because adding a `Duration` to `UNIX_EPOCH` is the standard way of constructing a `SystemTime` from a unix timestamp.
This PR implements `checked_add_duration(&self, &Duration) -> Option<SystemTime>` for `std::time::SystemTime` and as a prerequisite also for all platform specific time structs. This also led to the refactoring of many `add_duration(&self, &Duration) -> SystemTime` functions to avoid redundancy (they now unwrap the result of `checked_add_duration`).
Some basic unit tests for the newly introduced function were added too.
I wasn't sure which stabilization attribute to add to the newly introduced function, so I just chose `#[stable(feature = "time_checked_add", since = "1.32.0")]` for now to make it compile. Please let me know how I should change it or if I violated any other conventions.
P.S.: I could only test on Linux so far, so I don't necessarily expect it to compile for all platforms.
|
|
|
|
|
|
Since SystemTime is opaque there is no way to check if the result
of an addition will be in bounds. That makes the Add<Duration>
trait completely unusable with untrusted data. This is a big problem
because adding a Duration to UNIX_EPOCH is the standard way of
constructing a SystemTime from a unix timestamp.
This commit implements checked_add_duration(&self, &Duration) -> Option<SystemTime>
for std::time::SystemTime and as a prerequisite also for all platform
specific time structs. This also led to the refactoring of many
add_duration(&self, &Duration) -> SystemTime functions to avoid
redundancy (they now unwrap the result of checked_add_duration).
Some basic unit tests for the newly introduced function were added
too.
|
|
fix various typos in doc comments
|
|
Unix RwLock: avoid racy access to write_locked
We should only access `write_locked` if we really got the lock.
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
refactor: use shorthand fields
refactor: use shorthand for single fields everywhere (excluding tests).
|
