PassWrapper: adapt for llvm/llvm-project@b01e2a8b56
A boolean turned into an enum. None matches the old behavior of false, so we pass that.
`@rustbot` label: +llvm-main
Subtree sync for rustc_codegen_cranelift
The highlight this time is an update to Cranelift 0.113,
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Add `--print host-tuple` to print host target tuple
People often parse `-vV` output to get to the host tuple, which is annoying to do. It's easier to just get it directly.
I called it "host-tuple" instead of "host" because it's clearer that it's just the target name. I'm open to different names, but I think this one is fine.
a quick GitHub search for `'^host` reveals many instances of people doing the parsing, for example:
68e0ca57cd/README.md (L369)0e38473b0c/main.sh (L96)8a3553b865/README.md (L625)43f3ec3970/do.sh (L35)
needs a compiler FCP. I could also do an MCP but I think just an FCP here makes the most sense.
Tweak E0277 output when a candidate is available
*Follow up to #132086.*
Go from
```
error[E0277]: the trait bound `Then<Ignored<chumsky::combinator::Filter<chumsky::primitive::Any<&str, chumsky::extra::Full<EmptyErr, (), ()>>, {closure@src/main.rs:9:17: 9:27}>, char>, chumsky::combinator::Map<impl CSTParser<'a, O>, O, {closure@src/main.rs:11:24: 11:27}>, (), (), chumsky::extra::Full<EmptyErr, (), ()>>: CSTParser<'a>` is not satisfied
--> src/main.rs:7:50
|
7 | fn leaf<'a, O>(parser: impl CSTParser<'a, O>) -> impl CSTParser<'a, ()> {
| ^^^^^^^^^^^^^^^^^^^^^^ the trait `chumsky::private::ParserSealed<'_, &str, (), chumsky::extra::Full<EmptyErr, (), ()>>` is not implemented for `Then<Ignored<Filter<Any<&str, ...>, ...>, ...>, ..., ..., ..., ...>`, which is required by `Then<Ignored<chumsky::combinator::Filter<chumsky::primitive::Any<&str, chumsky::extra::Full<EmptyErr, (), ()>>, {closure@src/main.rs:9:17: 9:27}>, char>, chumsky::combinator::Map<impl CSTParser<'a, O>, O, {closure@src/main.rs:11:24: 11:27}>, (), (), chumsky::extra::Full<EmptyErr, (), ()>>: CSTParser<'a>`
|
= help: the trait `chumsky::private::ParserSealed<'_, &'a str, ((), ()), chumsky::extra::Full<EmptyErr, (), ()>>` is implemented for `Then<Ignored<chumsky::combinator::Filter<chumsky::primitive::Any<&str, chumsky::extra::Full<EmptyErr, (), ()>>, {closure@src/main.rs:9:17: 9:27}>, char>, chumsky::combinator::Map<impl CSTParser<'a, O>, O, {closure@src/main.rs:11:24: 11:27}>, (), (), chumsky::extra::Full<EmptyErr, (), ()>>`
= help: for that trait implementation, expected `((), ())`, found `()`
= note: required for `Then<Ignored<Filter<Any<&str, ...>, ...>, ...>, ..., ..., ..., ...>` to implement `Parser<'_, &str, ()>`
note: required for `Then<Ignored<Filter<Any<&str, ...>, ...>, ...>, ..., ..., ..., ...>` to implement `CSTParser<'a>`
--> src/main.rs:5:16
|
5 | impl<'a, O, T> CSTParser<'a, O> for T where T: Parser<'a, &'a str, O> {}
| ^^^^^^^^^^^^^^^^ ^ ---------------------- unsatisfied trait bound introduced here
= note: the full name for the type has been written to '/home/gh-estebank/longlong/target/debug/deps/longlong-0008f9a4f2023b08.long-type-13239977239800463552.txt'
= note: consider using `--verbose` to print the full type name to the console
= note: the full name for the type has been written to '/home/gh-estebank/longlong/target/debug/deps/longlong-0008f9a4f2023b08.long-type-13239977239800463552.txt'
= note: consider using `--verbose` to print the full type name to the console
```
to
```
error[E0277]: the trait bound `Then<Ignored<chumsky::combinator::Filter<chumsky::primitive::Any<&str, chumsky::extra::Full<EmptyErr, (), ()>>, {closure@src/main.rs:9:17: 9:27}>, char>, chumsky::combinator::Map<impl CSTParser<'a, O>, O, {closure@src/main.rs:11:24: 11:27}>, (), (), chumsky::extra::Full<EmptyErr, (), ()>>: CSTParser<'a>` is not satisfied
--> src/main.rs:7:50
|
7 | fn leaf<'a, O>(parser: impl CSTParser<'a, O>) -> impl CSTParser<'a, ()> {
| ^^^^^^^^^^^^^^^^^^^^^^ unsatisfied trait bound
...
11 | ws.then(parser.map(|_| ()))
| --------------------------- return type was inferred to be `Then<Ignored<..., ...>, ..., ..., ..., ...>` here
|
= help: the trait `ParserSealed<'_, &_, (), Full<_, _, _>>` is not implemented for `Then<Ignored<..., ...>, ..., ..., ..., ...>`
but trait `ParserSealed<'_, &'a _, ((), ()), Full<_, _, _>>` is implemented for it
= help: for that trait implementation, expected `((), ())`, found `()`
= note: required for `Then<Ignored<..., ...>, ..., ..., ..., ...>` to implement `Parser<'_, &str, ()>`
note: required for `Then<Ignored<..., ...>, ..., ..., ..., ...>` to implement `CSTParser<'a>`
--> src/main.rs:5:16
|
5 | impl<'a, O, T> CSTParser<'a, O> for T where T: Parser<'a, &'a str, O> {}
| ^^^^^^^^^^^^^^^^ ^ ---------------------- unsatisfied trait bound introduced here
= note: the full name for the type has been written to '/home/gh-estebank/longlong/target/debug/deps/longlong-df9d52be87eada65.long-type-1337037744507305372.txt'
= note: consider using `--verbose` to print the full type name to the console
```
* Remove redundant wording
* Introduce trait diff highlighting logic and use it
* Fix incorrect "long type written to path" logic (can be split off)
* Point at tail expression in more cases in E0277
* Avoid long primary span labels in E0277 by moving them to a `help`
Fix#132013.
There are individual commits that can be their own PR. If the review load is too big, happy to split them off.
We don't see a reason to explicitly pass the default here, so just use
the default instead of explicitly passing it and needing an ifdef.
@rustbot label: +llvm-main
Also treat `impl` definition parent as transparent regarding modules
This PR changes the `non_local_definitions` lint logic to also consider `impl` definition parent as transparent regarding modules.
See tests and explanation in the changes.
``````@rustbot`````` label +L-non_local_definitions
Fixes *(after beta-backport)* #132427
cc ``````@leighmcculloch``````
r? ``````@jieyouxu``````
Move versioned Apple LLVM targets from `rustc_target` to `rustc_codegen_ssa`
Fully specified LLVM targets contain the OS version on macOS/iOS/tvOS/watchOS/visionOS, and this version depends on the deployment target environment variables like `MACOSX_DEPLOYMENT_TARGET`, `IPHONEOS_DEPLOYMENT_TARGET` etc.
We would like to move this to later in the compilation pipeline, both because it feels impure to access environment variables when fetching target information, but mostly because we need access to more information from https://github.com/rust-lang/rust/pull/130883 to do https://github.com/rust-lang/rust/issues/118204. See also https://github.com/rust-lang/rust/pull/129342#issuecomment-2335156119 for some discussion.
The first and second commit does the actual refactor, it should be a non-functional change, the third commit adds diagnostics for invalid deployment targets, which are now possible to do because we have access to the session.
Tested with the same commands as in https://github.com/rust-lang/rust/pull/130435.
r? ``````@petrochenkov``````
Do not suggest `#[derive(Copy)]` when we wanted a `!Copy` type.
Do not say "`Copy` is not implemented for `T` but `Copy` is".
Do not talk about `Trait` having no implementations when `!Trait` was desired.
```
error[E0277]: the trait bound `{gen block@$DIR/gen_block_is_coro.rs:7:5: 7:8}: Coroutine` is not satisfied
--> $DIR/gen_block_is_coro.rs:6:13
|
LL | fn foo() -> impl Coroutine<Yield = u32, Return = ()> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Coroutine` is not implemented for `{gen block@$DIR/gen_block_is_coro.rs:7:5: 7:8}`
LL | gen { yield 42 }
| ---------------- return type was inferred to be `{gen block@$DIR/gen_block_is_coro.rs:7:5: 7:8}` here
```
The secondary span label is new.
When a trait is not implemented for a type, but there *is* an `impl`
for another type or different trait params, we format the output to
use highlighting in the same way that E0308 does for types.
The logic accounts for 3 cases:
- When both the type and trait in the expected predicate and the candidate are different
- When only the types are different
- When only the trait generic params are different
For each case, we use slightly different formatting and wording.
Rollup of 14 pull requests
Successful merges:
- #131829 (Remove support for `-Zprofile` (gcov-style coverage instrumentation))
- #132369 (style-guide: Only use the new binop heuristic for assignments)
- #132383 (Implement suggestion for never type fallback lints)
- #132413 (update offset_of! docs to reflect the stabilization of nesting)
- #132438 (Remove unncessary option for default rust-analyzer setting)
- #132439 (Add `f16` and `f128` to `invalid_nan_comparison`)
- #132444 (rustdoc: Directly use rustc_abi instead of reexports)
- #132445 (Cleanup attributes around unchecked shifts and unchecked negation in const)
- #132448 (Add missing backtick)
- #132450 (Show actual MIR when MIR building forgot to terminate block)
- #132451 (remove some unnecessary rustc_allow_const_fn_unstable)
- #132455 (make const_alloc_layout feature gate only about functions that are already stable)
- #132456 (Move remaining inline assembly test files into asm directory)
- #132459 (feat(byte_sub_ptr): unstably add ptr::byte_sub_ptr)
r? `@ghost`
`@rustbot` modify labels: rollup
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.
Double-check conditional constness in MIR
To prevent any unchecked `~const` bounds from leaking through during MIR lowering.
If this check fails, it will eventually just delay a bug, but for now it reports errors. That error reporting may be redundant if we're calling it from code that already doesn't allow `~const` (i.e. when the `effects` and `const_trait_impl` gates are disabled), but I don't think it's that big of a deal.
edit: This also makes sure that we issue a const stability error if we encounter *any* function with const conditions when `const_trait_impl` is not enabled. This ensures that that feature remains airtight.
The OS version depends on the deployment target environment variables,
the access of which we want to move to later in the compilation pipeline
that has access to more information, for example `env_depinfo`.
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
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`
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"`
|
```
