Move NaN tests to floats/mod.rs
This PR moves NaN tests to `floats/mod.rs`, as discussed in rust-lang/rust#141726. Since this is my first PR against Rust, I'm keeping it as small as possible, but I intend to work my way through the remaining tests and can do that work in this PR if that's preferable.
r? RalfJung
Fix `proc_macro::Ident`'s handling of `$crate`
This PR is addresses a few minor bugs, all relating to `proc_macro::Ident`'s support for `$crate`. `Ident` currently supports `$crate` (as can be seen in the `mixed-site-span` test), but:
* `proc_macro::Symbol::can_be_raw` is out of sync with `rustc_span::Symbol::can_be_raw`
* former doesn't cover `$crate` while the latter does cover `kw::DollarCrate`
* `Ident::new` rejects `$crate`
* This conflicts with the [reference definition](https://doc.rust-lang.org/nightly/reference/macros-by-example.html#r-macro.decl.meta.specifier) of `ident` which includes `$crate`.
* This also conflicts with the documentation on [`Display for Ident`](https://doc.rust-lang.org/proc_macro/struct.Ident.html#impl-Display-for-Ident) which says the output "should be losslessly convertible back into the same identifier".
This PR fixes the above issues and extends the `mixed-site-span` test to exercise these fixed code paths, as well as validating the different possible spans resolve `$crate` as expected (for both the new and old `$crate` construction code paths).
Fix in std::String docs
This PR removes the word “else” from the sentence ('something else similar') in the String documentation to improve clarity.
Fixesrust-lang/rust#143579.
doc(std): clarify `NonZero<T>` usage limitation in doc comment
Closesrust-lang/rust#142966
This PR clarifies `NonZero<T>` usage limitation in doc comment and fixes a typo.
r? libs
lib: more eagerly return `self.len()` from `ceil_char_boundary`
There is no reason to go through the complicated branch as it would
always return `self.len()` in this case. Also helps debug code somewhat
and I guess might make optimizations easier (although I haven't really a
sample to demonstrate this.)
ref. https://github.com/rust-lang/rust/issues/93743
Suggested by `@chrisduerr`
Renamed retain_mut to retain on LinkedList as mentioned in the ACP
This is for proposal: https://github.com/rust-lang/libs-team/issues/250
The original check-in (https://github.com/rust-lang/rust/pull/114136) contained both methods **retain** and **retain_mut**, which does not conform to https://github.com/rust-lang/libs-team/issues/250#issuecomment-1766822671.
I updated the retain documentation to specify **&mut e**, removed the **retain** method and renamed **retain_mut** to **retain** to conform to the request.
The pull request doesn't really contain much that is new, just removes the unwanted method to meet the requirements.
I've run the tests "library/alloc" on the code and no issues.
Hopefully I'm not stepping on the original author's toes. I just ran across a need for the method and wondered why it was unstable.
There is no reason to go through the complicated branch as it would
always return `self.len()` in this case. Also helps debug code somewhat
and I guess might make optimizations easier (although I haven't really a
sample to demonstrate this.)
ref. #93743
Suggested by @chrisduerr
The clock_nanosleep support is there to allow code using `sleep_until`
to run under Miri. Therefore the implementation is minimal.
- Only the clocks REALTIME and MONOTONIC are supported. The first is supported simply
because it was trivial to add not because it was needed for sleep_until.
- The only supported flag combinations are no flags or TIMER_ABSTIME only.
If an unsupported flag combination or clock is passed in this throws
unsupported.
Using clock nanosleep leads to more accurate sleep times on platforms
where it is supported.
To enable using clock_nanosleep this makes `sleep_until` platform
specific. That unfortunatly requires identical placeholder
implementations for the other platforms (windows/mac/wasm etc).
we will land platform specific implementations for those later. See the
`sleep_until` tracking issue.
This requires an accessors for the Instant type. As that accessor is only
used on the platforms that have clock_nanosleep it is marked as allow_unused.
32bit time_t targets do not use clock_nanosleep atm, they instead rely
on the same placeholder as the other platforms. We could make them
use clock_nanosleep too in the future using `__clock_nanosleep_time64`.
__clock_nanosleep_time64 is documented at:
https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html
use `is_multiple_of` and `div_ceil`
In tricky logic, these functions are much more informative than the manual implementations. They also catch subtle bugs:
- the manual `is_multiple_of` often does not handle division by zero
- manual `div_ceil` often does not consider overflow
The transformation is free for `is_multiple_of` if the divisor is compile-time known to be non-zero. For `div_ceil` there is a small cost to considering overflow. Here is some assembly https://godbolt.org/z/5zP8KaE1d.
move `va_copy`, `va_arg` and `va_end` to `core::intrinsics`
some questions:
- should these functions be `pub`?
- is a separate module justified?
r? `@RalfJung`
The `rustc` probe done in our build scripts needs to pass `--target` to
get the correct configuration, which usually comes from the `TARGET`
environment variable. However, for targets specified via a `target.json`
file, `TARGET` gets set to the file name without an extension or path.
`rustc` will check a search path to attempt to locate the file, but this
is likely to fail since the directory where Cargo invokes build scripts
(and hence where those scripts invoke `rustc`) might not have any
relation to the JSON spec file.
Resolve this for now by leaving `f16` and `f128` disabled if the `rustc`
command fails. Result of the discussion at CARGO-14208 may eventually
provide a better solution.
A CI test is also added since custom JSON files are an edge case that
could fail in other ways. I verified this fails without the fix here.
The JSON file is the output for `thumbv7em-none-eabi`, just renamed so
`rustc` doesn't identify it.
8521530f4938 ("Fix __divsi3 and __udivsi3 on thumbv6m targets") removed
tests that use these `thumb*-linux` target files in favor of tests that
use the `thumb*-none` targets, which are available via Rustup. The JSON
files haven't been used since then and are outdated, so remove them.
Make __rust_alloc_error_handler_should_panic a function
Fixesrust-lang/rust#143253
`__rust_alloc_error_handler_should_panic` is a static but was being exported as a function.
For most targets this doesn't matter, but Arm64EC Windows uses different decorations for exported variables vs functions, hence it fails to link when `-Z oom=abort` is enabled.
We've had issues in the past with statics like this (see rust-lang/rust#141061) but the tldr; is that Arm64EC needs symbols correctly exported as either a function or data, and data MUST and MUST ONLY be marked `dllimport` when the symbol is being imported from another binary, which is non-trivial to calculate for these compiler-generated statics.
So, instead, the easiest thing to do is to make `__rust_alloc_error_handler_should_panic` a function instead.
Since `__rust_alloc_error_handler_should_panic` isn't involved in any linking shenanigans, I've marked it as `AlwaysInline` with the hopes that the various backends will see that it is just returning a constant and perform the same optimizations as the previous implementation.
r? `@bjorn3`
