stdlib: Replace typedef -> type alias in doc comment
'typedef' is jargon from C and C++.
Since the Rust reference uses the term [type alias](https://doc.rust-lang.org/reference/items/type-aliases.html),
this patch changes the doc comment in io/error.rs
to also use 'type alias'.
std_detect: RISC-V: implement implication to "C"
Just like we implemented relatively complex rules to imply other extensions **from** "C" (and some others), this commit implements implication **to** the "C" extension from others, complying the following text in the ISA Manual (although there's no direct imply/depend references).
> The C extension is the superset of the following extensions:
>
> - Zca
> - Zcf if F is specified (RV32 only)
> - Zcd if D is specified
This is formally verified so that no other extension combinations (*not* in this implementation) can (currently) imply the "C" extension.
Note: this is a `std_detect` change and not main target feature handling.
add a fallback implementation for the `prefetch_*` intrinsics
related ACP: https://github.com/rust-lang/libs-team/issues/638
The fallback is to just ignore the arguments. That is a valid implementation because this intrinsic is just a hint.
I also added the `miri::intrinsic_fallback_is_spec` annotation, so that miri now supports these operations. A prefetch intrinsic call is valid on any pointer. (specifically LLVM guarantees this https://llvm.org/docs/LangRef.html#llvm-prefetch-intrinsic)
Next, I made the `LOCALITY` argument a const generic. That argument must be const (otherwise LLVM crashes), but that was not reflected in the type.
Finally, with these changes, the intrinsic can be safe and `const` (a prefetch at const evaluation time is just a no-op).
cc `@Amanieu`
r? `@RalfJung`
Remove the std workspace patch for `compiler-builtins`
All dependencies of `std` have dropped the crates.io dependency on `compiler-builtins`, so this patch is no longer needed.
Closes: RUST-142265
`std_detect`: Use `rustc-std-workspace-*` to pull in `compiler-builtins`
https://github.com/rust-lang/rust/pull/145489 changed `std_detect` to no
longer depend on `cfg-if`, which meant it no longer indirectly pulled in
`rustc-std-workspace-core` via `cfg-if`. That caused it to no longer
depend on `compiler-builtins`.
Change `std_detect` to use `rustc-std-workspace-core` and
`rustc-std-workspace-alloc`, to integrate with the rustc workspace. This
also pulls in `compiler-builtins` via `rustc-std-workspace-core`.
Closes: https://github.com/rust-lang/rust/issues/145594
Add runtime detection for APX-F and AVX10
This was missed in rust-lang/rust#139534 and rust-lang/rust#139675
`@rustbot` label O-x86_64 O-x86_32 A-target-feature
r? `@Amanieu`
std_detect: RISC-V platform guide documentation
This is practically a revert of a revert, making the commit e907456b2e10622ccd854a3bba8d02ce170b5dbb on `stdarch` come around again with minor fixes, enhancements and adjustments.
An excerpt from the original commit message follows:
Since there's no architectural feature detection on RISC-V (unlike `CPUID` on x86 architectures and some system registers on Arm/AArch64), runtime feature detection entirely depends on the platform-specific facility.
As a result, availability of each feature heavily depends on the platform and its version.
To help users make a decision for feature checking on a RISC-V system, this commit adds a platform guide with minimum supported platform versions.
Implement feature `int_lowest_highest_one` for integer and NonZero types
Tracking issue: rust-lang/rust#145203
Implement the accepted ACP rust-lang/rust#145203 for methods that find the index of the least significant (lowest) and most significant (highest) set bit in an integer for signed, unsigned, and NonZero types.
Also add unit tests for all these types.
Clarify EOF handling for `BufRead::skip_until`
This aligns `BufRead::skip_until`'s description more with `BufRead::read_until` in terms of how it handles EOF and extends the doctest to include this behavior.
Fix parameter order for `_by()` variants of `min` / `max`/ `minmax` in `std::cmp`
We saw a regression introduced in version `1.86` that seems to be coming from switching the order of `v1` and `v2` when calling `comparison` functions in `min_by` / `max_by` / `minmax_by` (cf. this PR: https://github.com/rust-lang/rust/pull/136307)
When the `compare` function is not symmetric in the arguments, this leads to false results. Apparently, the test cases do not cover this scenario currently. While asymmetric comparison may be an edge case, but current behavior is unexpected nevertheless.
The fallback is to just ignore the arguments. That is a valid implementation because this intrinsic is just a hint.
I also added `miri::intrinsic_fallback_is_spec` annotation, so that miri now supports these operations. A prefetch intrinsic call is valid on any pointer.
https://github.com/rust-lang/rust/pull/145489 changed `std_detect` to no
longer depend on `cfg-if`, which meant it no longer indirectly pulled in
`rustc-std-workspace-core` via `cfg-if`. That caused it to no longer
depend on `compiler-builtins`.
Change `std_detect` to use `rustc-std-workspace-core` and
`rustc-std-workspace-alloc`, to integrate with the rustc workspace. This
also pulls in `compiler-builtins` via `rustc-std-workspace-core`.
Closes: https://github.com/rust-lang/rust/issues/145594
bufreader::Buffer::backshift: don't move the uninit bytes
previous code was perfectly sound because of MaybeUninit, but it did waste cycles on copying memory that is known to be uninitialized.
Rust build fails on OpenBSD after using file_lock feature
PR 130999 added the file_lock feature, but doesn't included OpenBSD in the supported targets (Tier 3 platform), leading to a compilation error ("try_lock() not supported").
Cc `@cberner`
Related to rust-lang/rust#130999
Hide docs for `core::unicode`
This module is perma-unstable and shouldn't show up in the public docs. If people want to see the docs for it, they can still run `RUSTDOCFLAGS=--document-hidden-items ./x doc library/core`.
dec2flt: Provide more valid inputs examples
I was just looking at the specifics of how the parsing is handled here and I wasn't sure if the examples were incomplete or the grammar below was misleading.
The grammar was correct so I figured I'd add these examples to clarify.
Correct some grammar in integer documentation
Update "between" to "among" (more than two items), connect the "which" dependent clause to the independent part, and remove the redundant "here".
Remove the `From` derive macro from prelude
The new `#[derive(From)]` functionality (implemented in https://github.com/rust-lang/rust/pull/144922) caused name resolution ambiguity issues (https://github.com/rust-lang/rust/issues/145524). The reproducer looks e.g. like this:
```rust
mod foo {
pub use derive_more::From;
}
use foo::*;
#[derive(From)] // ERROR: `From` is ambiguous
struct S(u32);
```
It's pretty unfortunate that it works like this, but I guess that there's not much to be done here, and we'll have to wait for the next edition to put the `From` macro into the prelude. That will probably require https://github.com/rust-lang/rust/pull/139493 to land.
I created a new module in core (and re-exported it in std) called `from`, where I re-exported the `From` macro. I *think* that since this is a new module, it should not have the same backwards incompatibility issue.
Happy to hear suggestions about the naming - maybe it would make sense as `core::macros::from::From`? But we already had a precedent in the `core::assert_matches` module, so I just followed suit.
Fixes: https://github.com/rust-lang/rust/issues/145524
r? ``@petrochenkov``
[RTE-513] Ignore sleep_until test on SGX
rust-lang/rust#141829 added a test for `sleep_until`: it checks whether its specification holds:
> Puts the current thread to sleep until the specified deadline has passed.
but in SGX there's no secure time source. There's only the ability to request the `insecure_time` from outside of the enclave through a [usercall](https://github.com/fortanix/rust-sgx/blob/master/intel-sgx/fortanix-sgx-abi/src/lib.rs#L590-L592) and the ability to [wait](https://github.com/rust-lang/rust/blob/master/library/std/src/sys/pal/sgx/abi/usercalls/mod.rs#L173-L179) for a certain event or timeout. But both are under the control of an attacker; users should not depend on the accuracy nor correctness of this time. We try to even enforce this by adding a +/-10% time interval to wait usercalls.
The current `thread::sleep_until` implementation uses this `wait` usercall. When a negative randomization interval is added to the timeout passed in `wait`, the test fails. As users should not rely on the correctness of any time inside the enclave, it should be considered an incorrect test on SGX. This PR ignores this test.
`impl PartialEq<{str,String}> for {Path,PathBuf}`
This is a revival of #105877
Comparison of paths and strings is expected to be possible and needed e.g. in tests. This change adds the impls os `PartialEq` between strings and paths, both owned and unsized, in both directions.
ACP: https://github.com/rust-lang/libs-team/issues/151
Just like we implemented relatively complex rules to imply other extensions
**from** "C" (and some others), this commit implements implication
**to** the "C" extension from others, complying the following text
in the ISA Manual (although there's no direct imply/depend references).
> The C extension is the superset of the following extensions:
>
> - Zca
> - Zcf if F is specified (RV32 only)
> - Zcd if D is specified
This is formally verified so that no other extension combinations
(*not* in this implementation) can (currently) imply the "C" extension.
library: Migrate from `cfg_if` to `cfg_select`
Migrate the standard library from using the external `cfg_if` crate to using the now-built-in `cfg_select` macro.
This does not yet eliminate the dependency from `library/std/Cargo.toml`, because while the standard library itself no longer uses `cfg_if`, it also incorporates the `backtrace` crate, which does.
Migration assisted by the following vim command (after selecting the full `cfg_if!` invocation):
```
'<,'>s/\(cfg_if::\)\?cfg_if/cfg_select/ | '<,'>s/^\( *\)} else {/\1}\r\1_ => {/c | '<,'>s/^\( *\)} else if #\[cfg(\(.*\))\] /\1}\r\1\2 => /e | '<,'>s/if #\[cfg(\(.*\))\] {/\1 => {/e
```
This is imperfect, but substantially accelerated the process. This prompts for confirmation on the `} else {` since that can also appear inside one of the arms. This also requires manual intervention to handle any multi-line conditions.
Implement the accepted ACP for methods that find the index of the least
significant (lowest) and most significant (highest) set bit in an
integer for signed, unsigned, and NonZero types.
Also add unit tests for all these types.
