Implement the internal feature `cfg_target_has_reliable_f16_f128`
Support for `f16` and `f128` is varied across targets, backends, and backend versions. Eventually we would like to reach a point where all backends support these approximately equally, but until then we have to work around some of these nuances of support being observable.
Introduce the `cfg_target_has_reliable_f16_f128` internal feature, which provides the following new configuration gates:
* `cfg(target_has_reliable_f16)`
* `cfg(target_has_reliable_f16_math)`
* `cfg(target_has_reliable_f128)`
* `cfg(target_has_reliable_f128_math)`
`reliable_f16` and `reliable_f128` indicate that basic arithmetic for the type works correctly. The `_math` versions indicate that anything relying on `libm` works correctly, since sometimes this hits a separate class of codegen bugs.
These options match configuration set by the build script at [1]. The logic for LLVM support is duplicated as-is from the same script. There are a few possible updates that will come as a follow up.
The config introduced here is not planned to ever become stable, it is only intended to replace the build scripts for `std` tests and `compiler-builtins` that don't have any way to configure based on the codegen backend.
MCP: https://github.com/rust-lang/compiler-team/issues/866
Closes: https://github.com/rust-lang/compiler-team/issues/866
[1]: 555e1d0386/library/std/build.rs (L84-L186)
---
The second commit makes use of this config to replace `cfg_{f16,f128}{,_math}` in `library/`. I omitted providing a `cfg(bootstrap)` configuration to keep things simpler since the next beta branch is in two weeks.
try-job: aarch64-gnu
try-job: i686-msvc-1
try-job: test-various
try-job: x86_64-gnu
try-job: x86_64-msvc-ext2
Implement a lint for implicit autoref of raw pointer dereference - take 2
*[t-lang nomination comment](https://github.com/rust-lang/rust/pull/123239#issuecomment-2727551097)*
This PR aims at implementing a lint for implicit autoref of raw pointer dereference, it is based on #103735 with suggestion and improvements from https://github.com/rust-lang/rust/pull/103735#issuecomment-1370420305.
The goal is to catch cases like this, where the user probably doesn't realise it just created a reference.
```rust
pub struct Test {
data: [u8],
}
pub fn test_len(t: *const Test) -> usize {
unsafe { (*t).data.len() } // this calls <[T]>::len(&self)
}
```
Since #103735 already went 2 times through T-lang, where they T-lang ended-up asking for a more restricted version (which is what this PR does), I would prefer this PR to be reviewed first before re-nominating it for T-lang.
----
Compared to the PR it is as based on, this PR adds 3 restrictions on the outer most expression, which must either be:
1. A deref followed by any non-deref place projection (that intermediate deref will typically be auto-inserted)
2. A method call annotated with `#[rustc_no_implicit_refs]`.
3. A deref followed by a `addr_of!` or `addr_of_mut!`. See bottom of post for details.
There are several points that are not 100% clear to me when implementing the modifications:
- ~~"4. Any number of automatically inserted deref/derefmut calls." I as never able to trigger this. Am I missing something?~~ Fixed
- Are "index" and "field" enough?
----
cc `@JakobDegen` `@WaffleLapkin`
r? `@RalfJung`
try-job: dist-various-1
try-job: dist-various-2
Create `Atomic<T>` type alias (rebase)
Rebase of #130543.
Additional changes:
- Switch from `allow` to `expect` for `private_bounds` on `AtomicPrimitive`
- Unhide `AtomicPrimitive::AtomicInner` from docs, because rustdoc shows the definition `pub type Atomic<T> = <T as AtomicPrimitive>::AtomicInner;` and generated links for it.
- `NonZero` did not have this issue, because they kept the new alias private before the direction was changed.
- Use `Atomic<_>` in more places, including inside `Once`'s `Futex`. This is possible thanks to https://github.com/rust-lang/rust-clippy/pull/14125
The rest will either get moved back to #130543 or #130543 will be closed in favor of this instead.
---
* ACP: https://github.com/rust-lang/libs-team/issues/443#event-14293381061
* Tracking issue: #130539
docs: fix incorrect stability markers on `std::{todo, matches}`
This regression appeared in 916cfbcd3ed95a737b5a62103bbc4118ffe1eb2b. The change is behaving as expected (a non-glob re-export uses the stability marker on the `use` item, not the original one), but this part of the standard library didn't follow it.
Fixes https://github.com/rust-lang/rust/issues/140344
New compiler configuration has been introduced that is designed to
replace the build script configuration `reliable_f16`, `reliable_f128`,
`reliable_f16_math`, and `reliable_f128_math`. Do this replacement here,
which allows us to clean up `std`'s build script.
All tests are gated by `#[cfg(bootstrap)]` rather than doing a more
complicated `cfg(bootstrap)` / `cfg(not(bootstrap))` split since the
next beta split is within two weeks.
Stabilise `std::ffi::c_str`
This finished FCP in #112134 but never actually got a stabilisation PR. Since the FCP in #120048 recently passed to add the `os_str` module, it would be nice to also merge this too, to ensure that both get added in the next version.
Note: The added stability attributes which *somehow* were able to be omitted before (rustc bug?) were added based on the fact that they were added in 302551388b1942bb4216bb5a15d9d55cee3643a8, which ended up in 1.85.0.
Closes: https://github.com/rust-lang/rust/issues/112134
r? libs-api
This regression appeared in 916cfbcd3ed95a737b5a62103bbc4118ffe1eb2b.
The change is behaving as expected (a non-glob re-export uses the
stability marker on the `use` item, not the original one), but
this part of the standard library didn't follow it.
Document that "extern blocks must be unsafe" in Rust 2024
The [documentation on `extern`](https://doc.rust-lang.org/std/keyword.extern.html) contains the following code sample:
```rust
#[link(name = "my_c_library")]
extern "C" {
fn my_c_function(x: i32) -> bool;
}
```
Due to #123743, attempting to compile such code with the 2024 edition of Rust fails:
```
error: extern blocks must be unsafe
```
This PR extends the `extern` documentation with a brief explanation of the new requirement. It also adds the missing `unsafe` keyword to the code sample, which should be compatible with rustc since v1.82.
**Related docs:**
- https://doc.rust-lang.org/reference/items/external-blocks.html
- https://doc.rust-lang.org/edition-guide/rust-2024/unsafe-extern.html
Rollup of 8 pull requests
Successful merges:
- #137683 (Add a tidy check for GCC submodule version)
- #138968 (Update the index of Result to make the summary more comprehensive)
- #139572 (docs(std): mention const blocks in const keyword doc page)
- #140152 (Unify the format of rustc cli flags)
- #140193 (fix ICE in `#[naked]` attribute validation)
- #140205 (Tidying up UI tests [2/N])
- #140284 (remove expect() in `unnecessary_transmutes`)
- #140290 (rustdoc: fix typo change from equivelent to equivalent)
r? `@ghost`
`@rustbot` modify labels: rollup
Rollup of 8 pull requests
Successful merges:
- #137653 (Deprecate the unstable `concat_idents!`)
- #138957 (Update the index of Option to make the summary more comprehensive)
- #140006 (ensure compiler existance of tools on the dist step)
- #140143 (Move `sys::pal::os::Env` into `sys::env`)
- #140202 (Make #![feature(let_chains)] bootstrap conditional in compiler/)
- #140236 (norm nested aliases before evaluating the parent goal)
- #140257 (Some drive-by housecleaning in `rustc_borrowck`)
- #140278 (Don't use item name to look up associated item from trait item)
r? `@ghost`
`@rustbot` modify labels: rollup
Move `sys::pal::os::Env` into `sys::env`
Although `Env` (as `Vars`), `Args`, path functions, and OS constants are publicly exposed via `std::env`, their implementations are each self-contained. Keep them separate in `std::sys` and make a new module, `sys::env`, for `Env`.
Also fix `unsafe_op_in_unsafe_fn` for Unix and update the `!DynSend` and `!DynSync` impls which had grown out of sync with the platforms (see #48005 for discussion on that).
r? joboet
Tracked in #117276.
Deprecate the unstable `concat_idents!`
`concat_idents` has been around unstably for a long time, but there is now a better (but still unstable) way to join identifiers using `${concat(...)}` syntax with `macro_metavar_expr_concat`. This resolves a lot of the problems with `concat_idents` and is on a better track toward stabilization, so there is no need to keep both versions around. `concat_idents!` still has a lot of use in the ecosystem so deprecate it before removing, as discussed in [1].
Link: https://github.com/rust-lang/rust/issues/124225
[1]: https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Removing.20.60concat_idents.60
Work around cygwin issue on condvar timeout
This workaround *just works*... Actually I don't quite understand why does it work in such way. With a simple test on Cygwin, it seems that the maximum value of `tv_sec` could be 12899331056917, while the maximum value of `tv_nsec` should be a value floating around 464600000. A larger `timespec` could block the syscall forever.
r? `@joboet`
`concat_idents` has been around unstably for a long time, but there is
now a better (but still unstable) way to join identifiers using
`${concat(...)}` syntax with `macro_metavar_expr_concat`. This resolves
a lot of the problems with `concat_idents` and is on a better track
toward stabilization, so there is no need to keep both versions around.
`concat_idents!` still has a lot of use in the ecosystem so deprecate it
before removing, as discussed in [1].
Link: https://github.com/rust-lang/rust/issues/124225
[1]: https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Removing.20.60concat_idents.60
std: Add performance warnings to HashMap::get_disjoint_mut
Closes#139296
The `get_disjoint_mut` in `HashMap` also performs a complexity O(n^2) check. So we need to be reminded of that as well.
b5b0655a37/src/raw/mod.rs (L1216-L1220)
The extension is validated in `PathBuf::set_extension`, but not
`add_extension`. Fix that. Check for both / and \ path separators on
Windows, even when the path is verbatim, since this is logically like
`PathBuf::push` which normalizes separators (i.e., keeping the current
behavior).
Although `Env` (as `Vars`), `Args`, path functions, and OS constants are
publicly exposed via `std::env`, their implementations are each
self-contained. Keep them separate in `std::sys` and make a new module,
`sys::env`, for `Env`.
Clarify why SGX code specifies linkage/symbol names for certain statics
Specifying linkage/symbol name is solely to ensure a single instance between the `std` crate and its unit tests.
Also update the symbol names as items have moved around a bit. The actual name isn't that important, it just needs to be unique. But for debugging it can be useful for it to point to the right place.
Hermit: Unify `std::env::args` with Unix
The only differences between these implementations of `std::env::args` are that Unix uses relaxed ordering, but Hermit uses acquire/release, and Unix truncates `argv` at the first null pointer, but Hermit doesn't. Since Hermit aims for Unix compatibility, unify it with Unix.
The atomic orderings were established in https://github.com/rust-lang/rust/pull/74006 (cc `@euclio)` for Unix and https://github.com/rust-lang/rust/pull/100579 (cc `@joboet)` for Hermit and, before those, they used mutexes and non-atomic statics. I think the difference in orderings is simply from them being changed at different times. The commented explanation for using acquire/release for Hermit is “to broadcast writes by the OS”. I'm not experienced enough with atomics to accurately judge, but I think acquire/release is stronger than needed. Either way, they should match.
Truncating at the first null pointer seems desirable, though I don't know whether it is necessary in practice on Hermit.
cc `@mkroening` `@stlankes` for Hermit
SystemTime doc tweaks
* Change the `UNIX_EPOCH` link in the `SystemTime` docs to point to the associated constant, not the module level constant. The former seems to be the recommended way to access it, since aiui the only reason the module constant exists in the first place is that associated constants weren't stable yet at the time.
* Reword the comment in the `SystemTime` example - "an error occurred!" is a tad misleading; I feel like it implies a system error out of our control while `SystemTimeError` is more of a logic error.
I was originally just gonna do the first thing but I noticed the second and figured I may as well.
I'm also somewhat surprised that there aren't more in-depth module level docs for `std::time`; they don't even mention `SystemTime` at all. I might make another PR for that but mainly just wanted to flag it.
Move `pal::env` to `std::sys::env_consts`
Combine the `std::env::consts` platform implementations as a single file. Use the Unix file as the base, since it has 28 entries, and fold the 8 singleton platforms into it. The Unix file was roughly grouped into Linux, Apple, BSD, and everything else, roughly in alphabetical order. Alphabetically order them to make it easier to maintain and discard the Unix-specific groups to generalize it to all platforms.
I'd prefer to have no fallback implementation, as I consider it a bug; however TEEOS, Trusty, and Xous have no definitions here. Since they otherwise have `pal` abstractions, that indicates that there are several platforms without `pal` abstractions which are also missing here. To support unsupported, create a little macro to handle the fallback case and not introduce ordering between the `cfg`s like `cfg_if!`.
I've named the module `std::sys::env_consts`, because they are used in `std::env::consts` and I intend to use the name `std::sys::env` for the combination of `Args` and `Vars`.
cc `@joboet` `@ChrisDenton`
Tracked in #117276.
They were roughly grouped into Linux, Apple, BSD, and everything else,
roughly in alphabetical order. Alphabetically order them to make it
easier to maintain and discard the Unix-specific groups to generalize it
to all platforms.
