tests: mark simple UI tests as check-pass
This changes 14 simple UI tests from build-pass to check-pass.
These tests cover type checking, trait bounds, closure inference, deprecation diagnostics, dyn compatibility, and variance. They do not need codegen or linking, so check-pass keeps the intended coverage while removing old FIXME(62277) markers.
NVPTX: Drop support for old architectures and old ISAs
This is the implementation of [this MCP](https://github.com/rust-lang/compiler-team/issues/965#issuecomment-3837320262)
I believe it was said that no FCP was needed, but if that is incorrect then the FCP is anyway scheduled to finish in 2 days so it can in any case be merged then.
Handle hkl const closures
I severely overthought this in rust-lang/rust#153818😆
The const closure trait solver impl is now in sync with the non-const closure trait solver impl.
disable naked-dead-code-elimination test if no RET mnemonic is available
this test emit x86_64 specific ret asm instruction and should not be compiled on any other arch.
Tweak irrefutable let else warning output
Fixes https://github.com/rust-lang/rust/issues/153454
Greeting!
This PR tweak diagnostic output for `irrefutable-let-else` patterns and adds a check for `let a = Some(b) else {...}`
Thanks for the review!
```
help: consider using `let Some(name) = case` to match on a specific variant
|
LL - let name = Some(case) else {
LL + let Some(name) = case else {
|
```
Only exclude the #155473 change for 1-byte bool-likes
That's the thing we handle differently in codegen (see `to_immediate_scalar`) so if the other ones are fine, that helps narrow it down further.
cc https://github.com/rust-lang/rust/pull/155473
Add regression test for #101363
Adds test for rust-lang/rust#101363
Since it's my first time adding tests, I'm not sure if the test itself, its location, or its name are appropriate.
[codex] tests: mark migrated UI tests as check-pass
## Summary
Migrate a small set of UI tests left behind by the `compile-pass` migration from `build-pass` to `check-pass`.
These tests exercise attributes, cfg_attr, range trait type checking, and reachable-code diagnostics. None of the changed tests need codegen or linking, so `check-pass` matches the intended coverage and removes the stale `FIXME(#62277)` notes.
## Validation
- `python x.py test tests/ui/attributes/attr-before-view-item.rs tests/ui/attributes/attr-before-view-item2.rs tests/ui/attributes/attr-mix-new.rs tests/ui/attributes/class-attributes-1.rs tests/ui/attributes/class-attributes-2.rs tests/ui/attributes/method-attributes.rs tests/ui/attributes/unrestricted-attribute-tokens.rs tests/ui/attributes/variant-attributes.rs tests/ui/conditional-compilation/cfg-attr-multi-false.rs tests/ui/conditional-compilation/cfg-attr-multi-true.rs tests/ui/range/range_traits-4.rs tests/ui/range/range_traits-5.rs tests/ui/range/range_traits-7.rs tests/ui/reachable/expr_andand.rs tests/ui/reachable/expr_oror.rs`
- `python x.py test tidy`
Add infrastructure to query LLVM backend for specific assembly mnemonics
and use it in compiletest to conditionally run tests based on instruction
availability.
This fixes test failures with naked-dead-code-elimination which requires
the `RET` mnemonic.
Co-authored-by: Folkert de Vries <flokkievids@gmail.com>
Remove `WithCachedTypeInfo::stable_hash`.
We store a stable hash value in the most common interned values (e.g. types, predicates, regions). This is 16 bytes of data.
- In non-incremental builds it's a straightforward performance loss: the stable hash isn't computed or used, and the 16 bytes of space goes to waste (but it still gets hashed when interning).
- In incremental builds it avoids some hashing but doesn't seem to actually be a genuine performance win, and the complexity doesn't seem worth it.
r? @oli-obk
Fix ICE: Scalar layout for non-primitive non-enum type unsafe binder
`UnsafeBinder` uses the inner layout, but the debug layout check still looked at the outer type. Check the inner type first so this does not ICE.
Tracking issue: rust-lang/rust#130516Closes: rust-lang/rust#154426
Remove `AttributeLintKind`
Part of https://github.com/rust-lang/rust/issues/153099.
The `AttributeLintKind` type is finally gone! \o/
Diff is this big because I moved a file and a lot of `Diagnostic` types. :')
r? @JonathanBrouwer
Create a new `SharedContext::emit_dyn_lint_with_sess` method to simplify code when `Session` is not needed
Remove crate name from `UnexpectedCfgCargoMacroHelp`
Fix pathological performance in trait solver cycles with errors
Fuchsia's Starnix system has had a multi-year long bug where occasionally a typo could cause the rust compiler to take 10+ hours to report an error (see rust-lang/rust#136516 and rust-lang/rust#150907). This was particularly hard to trace down since Starnix's codebase is massive, over 384 thousand lines as of writing.
With the help of treereduce, cargo-minimize, and rustmerge, after about a month of running we reduced it down to a couple [lines of code], which only takes about 35 seconds to report an error on my machine. The bug also appears to happen with `-Z next-solver=no` and `-Z next-solver=coherence`, but does not occur with `-Z next-solver` or `-Z next-solver=globally`.
I used Gemini to help diagnose the problem and proposed solution (which is the one proposed in this patch):
1. The trait solver gets stuck in an exponential loop evaluating auto-trait bounds (like Send and Sync) on cyclic types that contain compilation errors (TyKind::Error).
2. Normally, if the solver detects a cycle, it prevents the result from being stored in the Global Cache because the result depends on the current evaluation stack. However, when an error is involved, the depth tracking gets pinned to a low value, forcing the solver to rely on the short-lived Provisional Cache. Since the provisional cache is cleared between high-level iterations of the fulfillment loop, the solver ends up re-discovering and re-evaluating the same large cycle thousands of times.
3. Allow global caching of results even if they appear stack-dependent, provided that the inference context is already "tainted by errors" (`self.infcx.tainted_by_errors().is_some()`). This violates the strict invariant that global cache entries shouldn't depend on the stack, but it is safe because the compilation is already guaranteed to fail due to the presence of errors. Prioritizing compiler responsiveness and termination over perfect correctness in error states is the correct trade-off here.
I added the reduction as the test case for this. However, I don't see an easy way to catch if this bug comes back. Should we add some way to timeout the test if it takes longer than 10 seconds to compile? That could be a source of flakes though.
I don't have any experience with the trait solver code, but I did try to review the code to the best of my ability. This approach seems a bit of a bandaid to the solution, but I don't see a better solution. We could try to teach the solver to not clear the provisional cache in this circumstance, but I suspect that'd be a pretty invasive change.
I'm guessing if this does cause problems, it might report an incorrect error, but I (and Gemini) were unable to come up with an example that reported a different error with and without this fix.
Resolvesrust-lang/rust#150907
[lines of code]: https://gist.github.com/erickt/255bc4006292cac88de906bd6bd9220a
Check closure's constness validity in the constness query
fixesrust-lang/rust#155584
instead of checking during ast lowering, where it's not easily possible to obtain all the right information in time. While lowering an assoc item we don't know if the parent was a const trait or a const impl. Tracing this information is quite annoying, and complicates a lot of code, which checking here after the fact is trivial.
bors
