| 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
|
|
Hopefully just another routine update!
So far this starts to enable the `std::arch` in stage0 builds of rustc.
This means that we may need stage0/not(stage0) in stdsimd itself, but
more and more code is starting to use `std::arch` so I think it's time
to start shifting the balance of work here.
|
|
expand thread::park explanation
Cc @carllerche @parched @stjepang
|
|
|
|
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.
|
|
Fix bug in from_key_hashed_nocheck
|
|
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
|
|
r=QuietMisdreavus
Document `From` implementations
This PR is solves part of https://github.com/rust-lang/rust/issues/51430. It's my first PR, so I might need some guidance from @skade (as already mentioned in the issue).
The purpose of the PR is to document the `impl From` inside `path.rs` and answering the questions:
- What does it convert?
- Does it allocate memory?
- How expensive are the allocations?
I gave it a first shot, though an experienced rust developer might want to look over it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
make the C part of compiler-builtins opt-out
I'd like to be able to use Xargo to build a libstd without having a full C toolchain for the target. This is a start (but the fact that libstd is a dylib is still a problem).
However, compiler_builtin already has somewhat similar logic to not require a C compiler for wasm:
https://github.com/rust-lang-nursery/compiler-builtins/blob/fe74674f6e4be76d47b66f67d529ebf4186f4eb1/build.rs#L36-L41
(WTF GitHub, why doesn't this show an embedded code preview??)
I wonder if there is a way to not have two separate mechanisms? Like, move the above wasm logic to some place that controls the libstd feature, or so? Or is it okay to have these two mechanisms co-exist?
Cc @alexcrichton
|
|
Update issue number of `shrink_to` methods to point the tracking issue
Tracking issue: #56431
|
|
Remove some uses of try!
|
|
Stabilize dbg!(...)
Per FCP in https://github.com/rust-lang/rust/issues/54306 (which is ~1 day from completion).
r? @SimonSapin
The PR is fairly isolated so a rollup should probably work.
|
|
[std] Osstr len clarity
|
|
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.
|
|
Use raw_entry for more efficient interning
Fixes https://github.com/rust-lang/rust/issues/56308#issuecomment-442492744
|
|
Add libstd Cargo feature "panic_immediate_abort"
It stop asserts and panics from libstd to automatically
include string output and formatting code.
Use case: developing static executables smaller than 50 kilobytes,
where usual formatting code is excessive while keeping debuggability
in debug mode.
May resolve #54981.
|
|
|
|
|
|
|
|
It stop asserts and panics from libstd to automatically
include string output and formatting code.
Use case: developing static executables smaller than 50 kilobytes,
where usual formatting code is excessive while keeping debuggability
in debug mode.
May resolve #54981.
|
