remove some unnecessary rustc_allow_const_fn_unstable
These are either unstable functions that don't need the attribute, or the attribute refers to a feature that is already stable.
Cleanup attributes around unchecked shifts and unchecked negation in const
The underlying intrinsic is marked as "safe to expose on stable", so we shouldn't need any `rustc_allow_const_fn_unstable(unchecked_shifts)` anywhere. However, bootstrap rustc doesn't yet have the new const stability checks, so these changes only apply under `cfg(not(bootstrap))`.
rustdoc: Directly use rustc_abi instead of reexports
rustc_target reexports a lot of things that are in rustc_abi, but that will be over soon and now is probably a good time to switch. Uses of rustc_target remain where they inquire about the target tuple.
Add `f16` and `f128` to `invalid_nan_comparison`
Currently `f32_nan` and `f64_nan` are used to provide the `invalid_nan_comparison` lint. Since we have `f16_nan` and `f128_nan`, hook these up so the new float types get the same lints.
Implement suggestion for never type fallback lints
r? ```@WaffleLapkin```
Just opening this up for vibes; it's not done yet. I'd still like to make this suggestable in a few more cases before merge:
- [x] Try to annotate `_` -> `()`
- [x] Try to annotate local variables if they're un-annotated: `let x = ...` -> `let x: () = ...`
- [x] Try to annotate the self type of a `Trait::method()` -> `<() as Trait>::method()`.
The only other case we may want to suggest is a missing turbofish, like `f()` -> `f::<()>()`. That may be possible, but seems overly annoying.
This partly addresses https://github.com/rust-lang/rust/issues/132358; the other half of fixing that would be to make the error message a bit better, perhaps just special casing the `?` operator 🤔 I don't think I'll do that part.
Remove support for `-Zprofile` (gcov-style coverage instrumentation)
Tracking issue: #42524
MCP: https://github.com/rust-lang/compiler-team/issues/798
---
This PR removes the unstable `-Zprofile` flag, which enables ”gcov-style” coverage instrumentation, along with its associated `-Zprofile-emit` configuration flag.
(The profile flag predates and is almost entirely separate from the stable `-Cinstrument-coverage` flag.)
Notably, the `-Zprofile` flag:
- Is largely untested in-tree, having only one run-make test that does not check whether its output is correct or useful.
- Has no known maintainer.
- Has seen no push towards stabilization.
- Has at least one severe regression reported in 2022 that apparently remains unaddressed.
- #100125
- Is confusingly named, since it appears to be more about coverage than performance profiling, and has nothing to do with PGO.
- Is fundamentally limited by relying on counters auto-inserted by LLVM, with no knowledge of Rust beyond debuginfo.
rustc_target reexports a lot of things that are in rustc_abi, but
that will be over soon and now is probably a good time to switch.
Uses of rustc_target remain where they inquire about the target tuple.
Some where clause lowering simplifications
Rename `PredicateFilter::SelfThatDefines` to `PredicateFilter::SelfTraitThatDefines` to make it clear that it's only concerned with converting *traits*, and make it do a bit less work when converting bounds.
Also, make the predicate filter matching in `probe_ty_param_bounds_in_generics` explicit, and simply the args it receives a bit.
Remove support for decompressing dylib metadata
We haven't been compressing dylib metadata for a while now. Removing decompression support will regress error messages about an incompatible rustc version being used, but dylibs are pretty rare anyway.
Fixes https://github.com/rust-lang/rust-analyzer/issues/18451
Use protected visibility when building rustc with LLD
https://github.com/rust-lang/compiler-team/issues/782
I wasn't sure about having two commits in a PR, but I figured, at least initially it might make sense to discuss these commits together. Happy to squash, or move the second commit to a separate PR.
I contemplated trying to enable protected visibility for more cases when LLD will be used other than just `-Zlinker-features=+lld`, but that would be more a complex change that probably still wouldn't cover all cases when LLD is used, so went with the simplest option of just checking if the linker-feature is enabled.
r? lqd
Currently `f32_nan` and `f64_nan` are used to provide the
`invalid_nan_comparison` lint. Since we have `f16_nan` and `f128_nan`,
hook these up so the new float types get the same lints.
llvm: Match new LLVM 128-bit integer alignment on sparc
LLVM continues to align more 128-bit integers to 128-bits in the data layout rather than relying on the high level language to do it. Update SPARC target files to match and add a backcompat replacement for current LLVMs.
See llvm/llvm-project#106951 for details
`@rustbot` label: +llvm-main
r? `@durin42`
(Please wait for the LLVM CI to come back before approving), creating this PR to get it tested there.
Remove `""` case from RISC-V `llvm_abiname` match statement
For RISC-V, `""` isn't the always the same ABI as `"ilp32"`/`"lp64"` (`""` means LLVM will infer the ABI based on the enabled target features), but `create_object_file` currently assumes that it is. Since all RISC-V targets explicitly specify their ABI since #131807, this PR removes `""` from the match arm's pattern (meaning an empty string will now fall through to the `_ => bug!` arm).
r? `@workingjubilee`
macOS: Document the difference between Clang's `-darwin` and `-macosx` targets
`rustc`'s `*-apple-darwin` targets are badly named (they should've been called `*-apple-macos`), and this causes confusion wrt. the similarly named but somewhat incompatible Clang targets.
So let's document the difference to at least make things a _little_ easier on our users.
``@rustbot`` label O-macos A-docs
continue `TypingMode` refactor
There are still quite a few places which (indirectly) rely on the `Reveal` of a `ParamEnv`, but we're slowly getting there
r? `@compiler-errors`
compiler: Move `rustc_target::spec::abi::Abi` to `rustc_abi::ExternAbi`
Lift `enum Abi` from its rather odd place in the middle of rustc_target, and make it available again from rustc_abi. You know, the crate where you would expect the enum that describes all the ABIs to be? The platform-neutral ones, at least. This will help further refactoring of how we handle ABIs in the near future[^0].
Rename `Abi` to `ExternAbi` because quite a lot of the compiler overloads the concept of "ABI" enough that the existing name is imprecise and it is often renamed _anyway_. Often this was to avoid conflicts with the *other* type formerly known as `Abi` (now named BackendRepr[^1]), but sometimes it is just for clarity, and this name seems more self-explanatory. It does get reexported, though, using its old name, to reduce the odds of merge-conflicting over the entire tree.
All of `ExternAbi`'s friends come along for the ride, which costs adding some optional dependencies to the rustc_abi crate. However, all of this also allows simply moving three crates entirely off rustc_target:
- rustc_hir_pretty
- rustc_lint_defs
- rustc_mir_build
This odd selection is mostly to demonstrate a secondary motivation: The majority of the front-end of the compiler should be as target-agnostic as possible, and it is easier to assure this if they simply don't depend on the crate that describes targets. Note that I didn't migrate crates that don't benefit from it in this way yet, and I didn't survey every last crate.
[^0]: This is being undertaken as part of https://github.com/rust-lang/rust/issues/119183
[^1]: https://github.com/rust-lang/rust/pull/132246
Improve missing_abi lint
This is for the migration lint for https://github.com/rust-lang/rfcs/pull/3722
It is not yet marked as an edition migration lint, because `Edition2027` doesn't exist yet.
The lint now includes a machine applicable suggestion:
```
warning: extern declarations without an explicit ABI are deprecated
--> src/main.rs:3:1
|
3 | extern fn a() {}
| ^^^^^^ help: explicitly specify the C ABI: `extern "C"`
|
```
Fix validation when lowering `?` trait bounds
Pass the unlowered (`rustc_hir`) polarity to `lower_poly_trait_ref`.
This allows us to actually *validate* that generic args are actually valid on `?Trait` paths. This actually regressed in #113671 because that PR changed the behavior where we were inadvertently re-lowering paths as `BoundPolarity::Positive`, which was also coincidentally the only place we were enforcing the generics on `?Trait` paths were correct.
Fix `target_os` for `mipsel-sony-psx`
Previously set to `target_os = "none"` and `target_env = "psx"` in [the PR introducing the target](https://github.com/rust-lang/rust/pull/102689/), but although the Playstation 1 is _close_ to a bare metal target in some regards, it's still very much an operating system, so we should instead set `target_os = "psx"`.
This also matches the `mipsel-sony-psp` target, which sets `target_os = "psp"`.
CC target maintainer ``@ayrtonm.``
If there's any code out there that uses `cfg(target_env = "psx")`, they can use `cfg(any(target_os = "psx", target_env = "psx"))` until they bump their MSRV to a version where this is fully fixed.
LLVM continues to align more 128-bit integers to 128-bits in the data
layout rather than relying on the high level language to do it. Update
SPARC target files to match and add a backcompat replacement for current
LLVMs.
See llvm/llvm-project#106951 for details
Mark `simplify_aggregate_to_copy` mir-opt as unsound
Mark the `simplify_aggregate_to_copy` mir-opt added in #128299 as unsound as it seems to miscompile the MCVE reported in https://github.com/rust-lang/rust/issues/132353. The mir-opt can be re-enabled once this case is fixed.
```rs
fn pop_min(mut score2head: Vec<Option<usize>>) -> Option<usize> {
loop {
if let Some(col) = score2head[0] {
score2head[0] = None;
return Some(col);
}
}
}
fn main() {
let min = pop_min(vec![Some(1)]);
println!("min: {:?}", min);
// panic happens here on beta in release mode
// but not in debug mode
min.unwrap();
}
```
This MCVE is included as a `run-pass` ui regression test in the first commit. I built the ui test with a nightly manually, and can reproduce the behavioral difference with `-C opt-level=0` and `-C opt-level=1`. Locally, this ui test will fail unless it was run on a compiler built with the second commit marking the mir-opt as unsound thus disabling it by default.
This PR **partially reverts** commit e7386b3, reversing changes made to 02b1be1. The mir-opt implementation is just marked as unsound but **not** reverted to make reland reviews easier. Test changes are **reverted if they were not pure additions**. Tests added by the original PR received `-Z unsound-mir-opts` compile-flags.
cc `@DianQK` `@cjgillot` (PR author and reviewer of #128299)
Rollup of 5 pull requests
Successful merges:
- #130693 (Add `minicore` test auxiliary and support `//@ add-core-stubs` directive in ui/assembly/codegen tests)
- #132316 (CI: use free runners for 3 fast windows jobs)
- #132354 (Add `lp64e` RISC-V ABI)
- #132395 (coverage: Avoid ICE when `coverage_cx` is unexpectedly unavailable)
- #132396 (CI: use free runners for x86_64-gnu-tools and x86_64-rust-for-linux)
r? `@ghost`
`@rustbot` modify labels: rollup
We haven't been compressing dylib metadata for a while now. Removing
decompression support will regress error messages about an incompatible
rustc version being used, but dylibs are pretty rare anyway.
