Reduce dependence on the target name
The target name can be anything with custom target specs. Matching on fields inside the target spec is much more robust than matching on the target name.
Also remove the unused is_builtin target spec field.
remove const-support for align_offset and is_aligned
As part of the recent discussion to stabilize `ptr.is_null()` in const context, the general vibe was that it's okay for a const function to panic when the same operation would work at runtime (that's just a case of "dynamically detecting that something is not supported as a const operation"), but it is *not* okay for a const function to just return a different result.
Following that, `is_aligned` and `is_aligned_to` have their const status revoked in this PR, since they do return actively wrong results at const time. In the future we can consider having a new intrinsic or so that can check whether a pointer is "guaranteed to be aligned", but the current implementation based on `align_offset` does not have the behavior we want.
In fact `align_offset` itself behaves quite strangely in const, and that support needs a bunch of special hacks. That doesn't seem worth it. Instead, the users that can fall back to a different implementation should just use const_eval_select directly, and everything else should not be made const-callable. So this PR does exactly that, and entirely removes const support for align_offset.
Closes some tracking issues by removing the associated features:
Closes https://github.com/rust-lang/rust/issues/90962
Closes https://github.com/rust-lang/rust/issues/104203
Cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api`
Generate correct symbols.o for sparc-unknown-none-elf
This fixes#130172 by selecting the correct ELF Machine type for sparc-unknown-none-elf (which has a baseline of SPARC V7).
Update `compiler-builtins` and enable f128 tests on all non-buggy platforms
Update compiler_builtins to 0.1.138 and pin it. This updates to a new version of builtins that includes [1], which was
the last blocker to us enabling `f128` tests on all platforms.
With that, we now provide symbols necessary to work with `f128` everywhere. This means that we are no longer restricted to systems that provide `f128` symbols themselves, and can enable tests by default.
There are still a handful of platforms that need to remain disabled because of bugs and some that had to get updated.
Math support is still off by default since those symbols are not yet available.
[1]: https://github.com/rust-lang/compiler-builtins/pull/624
try-job: test-various
try-job: i686-gnu-nopt
With the `compiler-builtins` update to 0.1.137 [1], we now provide
symbols necessary to work with `f128` everywhere. This means that we are
no longer restricted to 64-bit linux, and can enable tests by default.
There are still a handful of platforms that need to remain disabled
because of bugs. This patch additionally disables the following:
1. MIPS [2]
2. 32-bit x86 [3]
Math support is still off by default since those symbols are not yet
available.
[1]: https://github.com/rust-lang/rust/pull/132433
[2]: https://github.com/llvm/llvm-project/issues/96432
[3]: https://github.com/llvm/llvm-project/issues/77401
This updates to a new version of builtins that includes [1], which was
the last blocker to us enabling `f128` tests on all platforms 🎉.
With this update, also change to pinning the version with `=` rather
than using the default carat versioning. This is meant to ensure that
`compiler-builtins` does not get updated as part of the weekly
`Cargo.lock` update, since updates to this crate need to be intentional:
changes to rust-lang/rust and rust-lang/compiler-builtins sometimes need
to be kept in lockstep, unlike most dependencies, and sometimes these
updates can be problematic.
[1]: https://github.com/rust-lang/compiler-builtins/pull/624
compiler: Directly use rustc_abi almost everywhere
Use rustc_abi instead of rustc_target where applicable. This is mostly described by the following substitutions:
```rust
match path_substring {
rustc_target::spec::abi::Abi => rustc_abi::ExternAbi,
rustc_target::abi::call => rustc_target::callconv,
rustc_target::abi => rustc_abi,
}
```
A number of spot-fixes make that not quite the whole story.
The main exception is in 33edc68 where I get a lot more persnickety about how things are imported, especially in `rustc_middle::ty::layout`, not just from where. This includes putting an end to a reexport of `rustc_middle::ty::ReprOptions`, for the same reason that the rest of this change is happening: reexports mostly confound things.
This notably omits rustc_passes and the ast crates, as I'm still examining a question I have about how they do stability checking of `extern "Abi"` strings and if I can simplify their logic. The rustc_abi and rustc_target crates also go untouched because they will be entangled in that cleanup.
r? compiler-errors
replace manual time convertions with std ones, comptime time format parsing
First commit replaces few manual time conversions with std ones, second makes parsing of time format at compiletime.
Call the target libdir target libdir
Because it's the target libdir.
`--print` uses the same terminology, and it's a simple way to make it obviously different from `$sysroot/lib`.
Make `std::os::darwin` public
I'm not sure of the reasoning behind them not being public before, but I think they should be, just like `std::os::ios` and `std::os::macos` are public.
Additionally, I've merged their source code, as it was otherwise just a bunch of unnecessary duplication.
Ultimately, I've done this PR to fix `./x build library --target=aarch64-apple-tvos,aarch64-apple-watchos,aarch64-apple-visionos`, as that currently fails because of dead code warnings.
Since you reviewed https://github.com/rust-lang/rust/pull/121419
r? davidtwco
Fixes https://github.com/rust-lang/rust/issues/121640.
`@rustbot` label O-tvos O-watchos O-visionos
This is consistent with all other diagnostics I could find containing
features and enables the use of `DiagSymbolList` for generalizing
diagnostics for unstable library features to multiple features.
Yeet the `effects` feature, move it onto `const_trait_impl`
This PR merges the `effects` feature into the `const_trait_impl` feature. There's really no need to have two feature gates for one feature.
After this PR, if `const_trait_impl` **is** enabled:
* Users can use and define const traits
* `HostEffect` const conditions will be enforced on the HIR
* We re-check the predicates in MIR just to make sure that we don't "leak" anything during MIR lowering
And if `const_trait_impl` **is not** enabled:
* Users cannot use nor define const traits
* `HostEffect` const conditions are not enforced on the HIR
* We will raise a const validation error if we call a function that has any const conditions (i.e. const traits and functions with any `~const` in their where clasues)
This should be the last step for us to be able to enable const traits in the standard library. We still need to re-constify `Drop` and `Destruct` and stuff for const traits to be particularly *useful* for some cases, but this is a good step :D
r? fee1-dead
cc `@rust-lang/project-const-traits`
Use the right span when encountering an enum variant followed by an associated item so we don't lose the associated item in the resulting code.
Do not suggest the thing twice, once as a removal of the associated item and a second time as a typo suggestion.
The target name can be anything with custom target specs. Matching on
fields inside the target spec is much more robust than matching on the
target name.
Operations like is_aligned would return actively wrong results at compile-time,
i.e. calling it on the same pointer at compiletime and runtime could yield
different results. That's no good.
Instead of having hacks to make align_offset kind-of work in const-eval, just
use const_eval_select in the few places where it makes sense, which also ensures
those places are all aware they need to make sure the fallback behavior is
consistent.
This change updates the documentation for `NonZero` integer types to
explicitly reference the underlying integer type each `NonZero` variant
wraps, instead of using a general "integer" term.
This commit is the final step in the journey of renaming the historical
`wasm32-wasi` target in the Rust compiler to `wasm32-wasip1`. Various
steps in this journey so far have been:
* 2023-04-03: rust-lang/compiler-team#607 - initial proposal for this rename
* 2024-11-27: rust-lang/compiler-team#695 - amended schedule/procedure for rename
* 2024-01-29: rust-lang/rust#120468 - initial introduction of `wasm32-wasip1`
* 2024-06-18: rust-lang/rust#126662 - warn on usage of `wasm32-wasi`
* 2024-11-08: this PR - remove the `wasm32-wasi` target
The full transition schedule is in [this comment][comment] and is
summarized with:
* 2024-05-02: Rust 1.78 released with `wasm32-wasip1` target
* 2024-09-05: Rust 1.81 released warning on usage of `wasm32-wasi`
* 2025-01-09: Rust 1.84 to be released without the `wasm32-wasi` target
This means that support on stable for the replacement target of
`wasm32-wasip1` has currently been available for 6 months. Users have
already seen warnings on stable for 2 months about usage of
`wasm32-wasi` and stable users have another 2 months of warnings before
the target is removed from stable.
This commit is intended to be the final step in this transition so the
source tree should no longer mention `wasm32-wasi` except in historical
reference to the older name of the `wasm32-wasip1` target.
[comment]: https://github.com/rust-lang/rust/pull/120468#issuecomment-1977878747
Rollup of 15 pull requests
Successful merges:
- #129329 (Implement `From<&mut {slice}>` for `Box/Rc/Arc<{slice}>`)
- #131377 (Add LowerExp and UpperExp implementations to NonZero)
- #132393 (Docs: added brief colon explanation)
- #132437 (coverage: Regression test for inlining into an uninstrumented crate)
- #132499 (unicode_data.rs: show command for generating file)
- #132503 (better test for const HashMap; remove const_hash leftovers)
- #132511 (stabilize const_arguments_as_str)
- #132520 (NFC add known bug nr to test)
- #132522 (make codegen help output more consistent)
- #132523 (Added regression test for generics index out of bounds)
- #132528 (Use `*_opt` typeck results fns to not ICE in fallback suggestion)
- #132537 (PassWrapper: adapt for llvm/llvm-project@5445edb5d)
- #132540 (Do not format generic consts)
- #132543 (add and update some crashtests)
- #132550 (compiler: Continue introducing rustc_abi to the compiler)
r? `@ghost`
`@rustbot` modify labels: rollup
Port most of `--print=target-cpus` to Rust
The logic and formatting needed by `--print=target-cpus` has historically been carried out in C++ code. Originally it used `printf` to write directly to the console, but later it switched over to writing to a `std::ostringstream` and then passing its buffer to a callback function pointer.
This PR replaces that C++ code with a very simple function that writes a list of CPU names to a `&RustString`, with the rest of the logic and formatting being handled by ordinary safe Rust code.
