Emit warning while outputs is not exe and prints linkage info
cc #137384
```bash
$ rustc +stage1 /dev/null --print native-static-libs --crate-type staticlib --emit metadata
warning: skipping link step due to conflict: cannot output linkage information without emitting executable
note: consider emitting executable to print link information
warning: 1 warning emitted
```
GCI: At their def site, actually wfcheck the where-clause & always eval free lifetime-generic constants
* 1st commit: Partially addresses [#136204](https://github.com/rust-lang/rust/issues/136204) by turning const eval errors from post to pre-mono for free lifetime-generic constants.
* As the linked issue/comment states, on master there's a difference between `const _: () = panic!();` (pre-mono error) and `const _<'a>: () = panic!();` (post-mono error) which feels wrong.
* With this PR, both become pre-mono ones!
* 2nd commit: Oof, yeah, I missed that in the initial impl!
This doesn't fully address #136204 because I still haven't figured out how & where to properly & best suppress const eval of free constants whose predicates don't hold at the def site. The motivating example is `const _UNUSED: () = () where for<'_delay> String: Copy;` which can also be found over at the tracking issue #113521.
r? compiler-errors or reassign
Fix ICE in tokenstream with contracts from parser recovery
Fixesrust-lang/rust#140683
After two times of parsing error, the `recover_stmt_` constructs an error ast, then when we expand macors, the invalid tokenstream triggered ICE because of mismatched delims.
Expected `{` and get other tokens is an obvious error message, too much effort on recovery may introduce noise.
r? ```@nnethercote```
rustdoc: linking to a local proc macro no longer warns
fixes https://github.com/rust-lang/rust/issues/91274
tried to keep the fix general in case we ever have any other kind of item that occupies
multiple namespaces simultaniously.
Split `autodiff` into `autodiff_forward` and `autodiff_reverse`
This PR splits `#[autodiff]` macro so `#[autodiff(df, Reverse, args)]` would become `#[autodiff_reverse(df, args)]` and `#[autodiff(df, Forward, args)]` would become `#[autodiff_forwad(df, args)]`.
Make two transmute-related MIR lints into HIR lint
Make `PTR_TO_INTEGER_TRANSMUTE_IN_CONSTS` (rust-lang/rust#130540) and `UNNECESSARY_TRANSMUTES` (rust-lang/rust#136083) into "normal" HIR-based lints.
Funny enough this came up in the review of the latter (https://github.com/rust-lang/rust/pull/136083#issuecomment-2614301413), but I guess it just was overlooked.
But anywyas, there's no reason for these to be MIR lints; in fact, it makes the suggestions for them a bit more complicated than necessary.
Note that there's probably a few more simplifications and improvements to be done here. Follow-ups can be done in a separate PR, especially if they're about the messaging and suggestions themselves, which I didn't write.
gvn: bail out unavoidable non-ssa locals in repeat
Fixes#141251.
We cannot transform `*elem` to `array[idx1]` in the following code, as `idx1` has already been modified.
```rust
mir! {
let array;
let elem;
{
array = [*val; 5];
elem = &array[idx1];
idx1 = idx2;
RET = *elem;
Return()
}
}
```
Perhaps I could transform it to `array[0]`, but I prefer the conservative approach.
r? mir-opt
Make check-cfg diagnostics work in `#[doc(cfg(..))]`
This PR makes it so that the check-cfg `unexpected_cfgs` lint, is correctly emitted in `rustdoc`'s `#[doc(cfg(..))]`.
This is achieved by adding a custom trait to `cfg_matches` (the method that emits the lint) which permits `rustc` and `rustdoc` to each have their way to emitting lints (via buffered lints/AST for `rustc` and via `TyCtxt`/HIR for `rustdoc`).
The reason this is required is because buffered lints operates on the AST but `rustdoc` uses the HIR and by the time `rustdoc` calls `cfg_matches` we are way passed the point where buffered lints have been drain and emitted.
Best reviewed commit by commit.
r? `@jieyouxu` (for the compiler part)
r? `@GuillaumeGomez` (for the rustdoc part)
Add some track_caller info to precondition panics
Currently, when you encounter a precondition check, you'll always get the caller location of the implementation of the precondition checks. But with this PR, you'll be told the location of the invalid call. Which is useful.
I thought of this while looking at https://github.com/rust-lang/rust/pull/129642#issuecomment-2311703898.
The changes to `tests/ui/const*` happen because the const-eval interpreter skips `#[track_caller]` frames in its backtraces.
The perf implications of this are:
* Increased debug binary sizes. The caller_location implementation requires that the additional data we want to display here be stored in const allocations, which are deduplicated but not across crates. There is no impact on optimized build sizes. The panic path and the caller location data get optimized out.
* The compile time hit to opt-incr-patched bitmaps happens because the patch changes the line number of some function calls with precondition checks, causing us to go from 0 dirty CGUs to 1 dirty CGU.
* The other compile time hits are marginal but real, and due to doing a handful of new queries. Adding more useful data isn't completely free.
tests: mark option-niche-eq as fixed on LLVM 21
Some combination of recent Rust changes (between 3d86494a0d and aa57e46e24 from what I can tell) and changes in LLVM 21 (not recently, as best I can tell) have caused this test to start showing the behavior we want, so it's time to move this test to a proper place and mark it as fixed on LLVM 21.
~~Probably "fixes" rust-lang/rust#49892, but I'll let others make that call.~~
Closesrust-lang/rust#49892 unless we want to break out a dedicated issue for `Option<bool>::eq` on LLVM 20 (seems low-value).
`@rustbot` label llvm-main
coverage: Revert "unused local file IDs" due to empty function names
The changes to coverage metadata generation in rust-lang/rust#140847 appear to be the most likely cause of the `function name is empty` errors reported in rust-lang/rust#141577.
If that guess is correct, great. If not, no big deal.
---
This reverts commit 3b22c21dd8, reversing changes made to 5f292eea6d.
r? ghost
Some combination of recent Rust changes (between 3d86494a0d and
aa57e46e24 from what I can tell) and changes in LLVM 21 (not recently,
as best I can tell) have caused this test to start showing the behavior
we want, so it's time to move this test to a proper place and mark it as
fixed on LLVM 21.
Add `generic_arg_infer` test
I think most of our existing tests around behaviour of repeat expr inferred counts fail by not having enough inference progress, rather than by having enough inference progress but the element not actually implementing `Copy`.
Support `opaque_types_defined_by` for `SyntheticCoroutineBody`
We create a synthetic MIR body for the `AsyncFnOnce` impl for async closures. That body goes through all passes that a regular body does, including promotion.
Promotion sometimes requires computing that the type of an rvalue is `Freeze`, which requires computing the typing env of a body. This requires calling `opaque_types_defined_by` on the body's def id, which leads to an ICE today since we don't expect that query to be called for synthetic bodies.
While we could fix this by, for example, computing the typeck root of the body before calling a `TypingEnv` constructor, I think it's appropriate to do a more general fix here since I think it's reasonable that other passes might do analysis too.
Fixesrust-lang/rust#141466
r? ```@lcnr``` or ```@oli-obk```
Use more detailed spans in dyn compat errors within bodies
Within bodies we can employ the full dyn compat check query instead of only doing the minimal hir ty lowerer one. This in turn gives us better spans and also silences many follow-up duplicate or bogus errors.
alternative to https://github.com/rust-lang/rust/pull/141439, tho I think I could turn the delayed bug from that one into a bug now instead of having an error code path.
r? `@compiler-errors`
cc `@fmease`
Improve `ambiguous_wide_pointer_comparisons` lint compare diagnostics
This PR improves the `ambiguous_wide_pointer_comparisons` lint compare diagnostics: `cmp`/`partial_cmp`, but also the operators `<`/`>`/`>=`/`<=`, by:
1. removing the reference to `std::ptr::addr_eq` which only works for equality
2. and adding an `#[expect]` suggestion for keeping the current behavior
Fixesrust-lang/rust#141510
Fix `unused_braces` lint suggestion when encountering attributes
This PR fixes the `unused_braces` lint suggestion when encountering attributes by not removing them in the suggestion.
Fixesrust-lang/rust#141549
Deduplicate dyn compatibility violations due to coercion
Don't unnecessarily emit dyn compatibility violations due to coercion to a non-dyn-compatible target type.
For us to even have that target type, we would have had to write `dyn Trait` somewhere in source, and that would have led to us *already* emitting a dyn compatibility violation when checking that user written type is WF.
r? oli-obk
Properly analyze captures from unsafe binders
We need to represent the unsafe binder unwrap as an adjustment in HIR. Pretty straightforward b/c we already represent it as a projection elem in MIR.
Fixes#141418Fixes#141417
r? oli-obk
Emit dummy open drop for unsafe binder
Fixesrust-lang/rust#141394
We can't taint the body in wfcheck when we have a `T: Copy` bound failure, so we end up binding MIR here. Emit a dummy open drop so that drop elaboration doesn't fail.
r? oli-obk
