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
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#134696 (Implement `normalize_lexically`)
- rust-lang/rust#140539 (Simplify `attribute_groups`)
- rust-lang/rust#140863 ([rustdoc] Unify type aliases rendering with other ADT)
- rust-lang/rust#140936 (Clarify WTF-8 safety docs)
- rust-lang/rust#140952 (Specify that split_ascii_whitespace uses the same definition as is_ascii_whitespace)
- rust-lang/rust#141472 (Attempt to improve the `std::fs::create_dir_all` docs related to atomicity)
- rust-lang/rust#141502 (ci: move PR job x86_64-gnu-tools to codebuild)
- rust-lang/rust#141559 (const-check: stop recommending the use of rustc_allow_const_fn_unstable)
r? `@ghost`
`@rustbot` modify labels: rollup
const-check: stop recommending the use of rustc_allow_const_fn_unstable
I have seen way too many people see the compiler suggest this attribute and then just apply it without a second thought. This is bad. So let's just stop recommending it; for the rare case where someone needs it, they'll eventually ask us and that way we can be sure that it is truly needed. The dev-guide still also explains `rustc_allow_const_fn_unstable`.
Cc ``@rust-lang/wg-const-eval``
[rustdoc] Unify type aliases rendering with other ADT
Fixes#140739.
Better reviewed one commit at a time.
Just one thing I'm wondering: should we also render non-`repr` attributes? If so, I wonder if we shouldn't simply change `clean::TypeAlias` to contain the other ADT directly (`Struct`, `Enum` and `Union`) and remove the `TypeAlias::generics` field.
Can be done in a follow-up too.
cc ``@camelid``
r? ``@notriddle``
