Add support for Arm64EC to the Standard Library
Adds the final pieces so that the standard library can be built for arm64ec-pc-windows-msvc (initially added in #119199)
* Bumps `windows-sys` to 0.56.0, which adds support for Arm64EC.
* Correctly set the `isEC` parameter for LLVM's `writeArchive` function.
* Add `#![feature(asm_experimental_arch)]` to library crates where Arm64EC inline assembly is used, as it is currently unstable.
Document restricted_std
This PR aims to pin down exactly what restricted_std is meant to achieve and what it isn't.
This commit fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/87 by explaining why the error appears and what the choices the user has. The error describes how std cannot function without knowing about some form of OS/platform support. Any features of std that work without an OS should be moved to core/alloc (see https://github.com/rust-lang/rust/issues/27242https://github.com/rust-lang/rust/issues/103765).
Note that the message says "platform" and "environment" because, since https://github.com/rust-lang/rust/pull/120232, libstd can be built for some JSON targets. This is still unsupported (all JSON targets probably should be unstable https://github.com/rust-lang/wg-cargo-std-aware/issues/90), but a JSON target with the right configuration should hopefully have some partial libstd support.
I propose closing https://github.com/rust-lang/wg-cargo-std-aware/issues/69 as "Won't fix" since any support of std without properly configured os, vendor or env fields is very fragile considering future upgrades of Rust or dependencies. In addition there's no likely path to it being fixed long term (making std buildable for all targets being the only solution). This is distinct from tier 3 platforms with limited std support implemented (and as such aren't restricted_std) because these platforms can conceptually work in the future and std support should mainly improve over time.
The alternative to closing https://github.com/rust-lang/wg-cargo-std-aware/issues/69 is a new crate feature for std which escapes the restricted_std mechanism in build.rs. It could be used with the -Zbuild-std-features flag if we keep it permanently unstable, which I hope we can do anyway. A minor side-effect in this scenario is that std wouldn't be marked as unstable if documentation for it were generated with build-std.
cc ```@ehuss```
This PR aims to pin down exactly what restricted_std is meant to achieve
and what it isn't.
This commit fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/87
by explaining why the error appears and what the choices the user has.
The error describes how std cannot function without knowing about some
form of OS/platform support. Any features of std that work without an
OS should be moved to core/alloc (see https://github.com/rust-lang/rust/issues/27242https://github.com/rust-lang/rust/issues/103765).
Note that the message says "platform" and "environment" because, since
https://github.com/rust-lang/rust/pull/120232, libstd can be built for
some JSON targets. This is still unsupported (all JSON targets probably
should be unstable https://github.com/rust-lang/wg-cargo-std-aware/issues/90),
but a JSON target with the right configuration should hopefully have
some partial libstd support.
I propose closing https://github.com/rust-lang/wg-cargo-std-aware/issues/69
as "Won't fix" since any support of std without properly configured os,
vendor or env fields is very fragile considering future upgrades of Rust
or dependencies. In addition there's no likely path to it being fixed
long term (making std buildable for all targets being the only
solution). This is distinct from tier 3 platforms with limited std
support implemented (and as such aren't restricted_std) because these
platforms can conceptually work in the future and std support should
mainly improve over time.
The alternative to closing https://github.com/rust-lang/wg-cargo-std-aware/issues/69
is a new crate feature for std which escapes the restricted_std
mechanism in build.rs. It could be used with the -Zbuild-std-features
flag if we keep it permanently unstable, which I hope we can do anyway.
A minor side-effect in this scenario is that std wouldn't be marked as
unstable if documentation for it were generated with build-std.
Replace pthread `RwLock` with custom implementation
This is one of the last items in #93740. I'm doing `RwLock` first because it is more self-contained and has less tradeoffs to make. The motivation is explained in the documentation, but in short: the pthread rwlock is slow and buggy and `std` can do much better. I considered implementing a parking lot, as was discussed in the tracking issue, but settled for the queue-based version because writing self-balancing binary trees is not fun in Rust...
This is a rather complex change, so I have added quite a bit of documentation to help explain it. Please point out any part that could be explained better.
~~The read performance is really good, I'm getting 4x the throughput of the pthread version and about the same performance as usync/parking_lot on an Apple M1 Max in the usync benchmark suite, but the write performance still falls way behind what usync and parking_lot achieve. I tried using a separate queue lock like what usync uses, but that didn't help. I'll try to investigate further in the future, but I wanted to get some eyes on this first.~~ [Resolved](https://github.com/rust-lang/rust/pull/110211#issuecomment-1513682336)
r? `@m-ou-se`
CC `@kprotty`
Use `assert_unchecked` instead of `assume` intrinsic in the standard library
Now that a public wrapper for the `assume` intrinsic exists, we can use it in the standard library.
CC #119131
merge core_panic feature into panic_internals
I don't know why those are two separate features, but it does not seem intentional. This merge is useful because with https://github.com/rust-lang/rust/pull/118123, panic_internals is recognized as an internal feature, but core_panic is not -- but core_panic definitely should be internal.
move exposed-provenance APIs into separate feature gate
We have already stated explicitly for all the 'exposed' functions that
> Using this method means that code is *not* following strict provenance rules.
However, they were part of the same feature gate and still described as part of the strict provenance experiment. Unfortunately, their semantics are much less clear and certainly nowhere near stabilization, so in preparation for an attempt to stabilize the strict provenance APIs, I suggest we split the things related to "exposed" into their own feature gate. I also used this opportunity to better explain how Exposed Provenance fits into the larger plan here: this is *one possible candidate* for `as` semantics, but we don't know if it is actually viable, so we can't really promise that it is equivalent to `as`. If it works out we probably want to make `as` equivalent to the 'exposed' APIs; if it doesn't, we will remove them again and try to find some other semantics for `as`.
Add substring API for `OsStr`
This adds a method for taking a substring of an `OsStr`, which in combination with [`OsStr::as_encoded_bytes()`](https://doc.rust-lang.org/std/ffi/struct.OsStr.html#method.as_encoded_bytes) makes it possible to implement most string operations in safe code.
API:
```rust
impl OsStr {
pub fn slice_encoded_bytes<R: ops::RangeBounds<usize>>(&self, range: R) -> &Self;
}
```
Motivation, examples and research at https://github.com/rust-lang/libs-team/issues/306.
Tracking issue: #118485
cc `@epage`
r? libs-api
Implement thread parking for xous
This follows the pattern set by [the Windows parker](ddef56d5df/library/std/src/sys/windows/thread_parking.rs) when it uses keyed events. An atomic variable is used to track the state and optimize the fast path, while notifications are send via the ticktime server to block and unblock the thread.
ping `@xobs`
`@rustbot` label +T-libs +A-atomic
r? libs
Add `std:#️⃣:{DefaultHasher, RandomState}` exports (needs FCP)
This implements rust-lang/libs-team#267 to move the libstd hasher types to `std::hash` where they belong, instead of `std::collections::hash_map`.
<details><summary>The below no longer applies, but is kept for clarity.</summary>
This is a small refactor for #27242, which moves the definitions of `RandomState` and `DefaultHasher` into `std::hash`, but in a way that won't be noticed in the public API.
I've opened rust-lang/libs-team#267 as a formal ACP to move these directly into the root of `std::hash`, but for now, they're at least separated out from the collections code in a way that will make moving that around easier.
I decided to simply copy the rustdoc for `std::hash` from `core::hash` since I think it would be ideal for the two to diverge longer-term, especially if the ACP is accepted. However, I would be willing to factor them out into a common markdown document if that's preferred.
</details>
Works around #115199 by temporarily disabling CFI for core and std CFI
violations to allow the user rebuild and use both core and std with CFI
enabled using the Cargo build-std feature.
- Uses Simple Text Output Protocol and Simple Text Input Protocol
- Reading is done one character at a time
- Writing is done with max 4096 characters
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
Don't modify libstd to dump rustc ICEs
Do a much simpler thing and just dump a `std::backtrace::Backtrace` to file.
r? `@estebank` `@oli-obk`
Fixes#115610
Add initial libstd support for Xous
This patchset adds some minimal support to the tier-3 target `riscv32imac-unknown-xous-elf`. The following features are supported:
* alloc
* thread creation and joining
* thread sleeping
* thread_local
* panic_abort
* mutex
* condvar
* stdout
Additionally, internal support for the various Xous primitives surrounding IPC have been added as part of the Xous FFI. These may be exposed as part of `std::os::xous::ffi` in the future, however for now they are not public.
This represents the minimum viable product. A future patchset will add support for networking and filesystem support.
Also stabilizes saturating_int_assign_impl, gh-92354.
And also make pub fns const where the underlying saturating_*
fns became const in the meantime since the Saturating type was
created.
Xous passes slice pointers around in order to manipulate memory.
This is feature-gated behind `slice_ptr_len`. Xous is currently
the only target to use this feature, so gate it behind an OS flag.
Signed-off-by: Sean Cross <sean@xobs.io>
* remove `impl Provider for Error`
* rename `Demand` to `Request`
* update docstrings to focus on the conceptual API provided by `Request`
* move `core::any::{request_ref, request_value}` functions into `core::error`
* move `core::any::tag`, `core::any::Request`, an `core::any::TaggedOption` into `core::error`
* replace `provide_any` feature name w/ `error_generic_member_access`
* move `core::error::request_{ref,value} tests into core::tests::error module
* update unit and doc tests
reduce deps for windows-msvc targets for backtrace
(eventually) mirrors https://github.com/rust-lang/backtrace-rs/pull/543
Some dependencies of backtrace don't used on windows-msvc targets, so exclude them:
miniz_oxide (+ adler)
addr2line (+ gimli)
object (+ memchr)
This saves about 30kb of std.dll + 17.5mb of rlibs
It lints against features that are inteded to be internal to the
compiler and standard library. Implements MCP #596.
We allow `internal_features` in the standard library and compiler as those
use many features and this _is_ the standard library from the "internal to the compiler and
standard library" after all.
Marking some features as internal wasn't exactly the most scientific approach, I just marked some
mostly obvious features. While there is a categorization in the macro,
it's not very well upheld (should probably be fixed in another PR).
We always pass `-Ainternal_features` in the testsuite
About 400 UI tests and several other tests use internal features.
Instead of throwing the attribute on each one, just always allow them.
There's nothing wrong with testing internal features^^
Use `LazyLock` to lazily resolve backtraces
By using TAIT to name the initializing closure, `LazyLock` can be used to replace the current `LazilyResolvedCapture`.
Implement rust-lang/compiler-team#578.
When an ICE is encountered on nightly releases, the new rustc panic
handler will also write the contents of the backtrace to disk. If any
`delay_span_bug`s are encountered, their backtrace is also added to the
file. The platform and rustc version will also be collected.
Limit read size in `File::read_to_end` loop
Fixes#110650.
Windows file reads have perf overhead that's proportional to the buffer size. When we have a reasonable expectation that we know the file size, we can set a reasonable upper bound for the size of the buffer in one read call.
Add `tidy-alphabetical` to features in `alloc` & `std`
So that people have to keep them sorted in future, rather than just sticking them on the end where they conflict more often.
Follow-up to #110269
cc `@jyn514`
