ast_passes: unsupported arch w/ scalable vectors
Fixesrust-lang/rust#153593
Emit an error when attempting to compile a `#[rustc_scalable_vector]` type for a architecture that fundamentally doesn't support scalable vectors. Ultimately this is just a diagnostic improvement for an internal attribute as users should never be doing this.
r? @lqd
fix ICE in `const_c_variadic` when passing ZSTs
fixes https://github.com/rust-lang/rust/issues/153351
r? RalfJung
There was a mismatch between the caller and callee ABI where the caller does not pass ZST arguments, but the callee does expect them. Because ZSTs don't implement `VaArgSafe` the program must already be invalid if this comes up.
stop marking `deref_patterns` as an incomplete feature
This PR removes the `incomplete_feature` warning for `deref_patterns`. The reason given for this in the tracking issue (rust-lang/rust#87121) was
> Per policy, the `incomplete_feature` is supposed to stay on until the feature has an accepted RFC. We're slowly working on writing up that RFC so it'll take some more time unfortunately.
>
> I don't know of any compiler crashes it causes today. The feature should be pretty usable.
However, I could not find any evidence of such a policy. The [lint documentation](https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#incomplete-features) for `incomplete_features` also only mentions features that are more likely to cause errors.
There are also many other features without an RFC that are not considered incomplete, e.g. `macro_metavar_expr_concat`, `negative_impls` or `yeet_expr`.
The feature does not cause any known ICEs either.
The concrete motivation is to use this feature to replace `box_patterns` in the compiler and pave the way towards removing that legacy feature.
Always make tuple elements a coercion site
Previously we only used `check_expr_coercible_to_type` if we had an expectation (using `check_expr_with_expectation(NoExpectation)` otherwise). Normally that'd be fine, because without an expectation we can't insert a coercion anyway. However, for the case of never-to-any coercion specifically, we _do_ insert it eagerly, so this prevents some code from compiling, for example:
```rust
((),) = (loop {},);
```
With this PR we are always using `check_expr_coercible_to_type` (using an infer var if there is no expectation), which allows slightly more code to compile.
Fixesrust-lang/rust#112856
r? BoxyUwU
Emit an error when attempting to compile a `#[rustc_scalable_vector]`
type for a architecture that fundamentally doesn't support scalable
vectors. Ultimately this is just a diagnostic improvement for an internal
attribute as users should never be doing this.
Move some ui tests
> [!NOTE]
> I split the commits to make the review easier and to keep the git history easier to trace.
Renamed issue-xxx tests
`tests/ui/dyn-drop` -> `tests/ui/dyn-keyword`
`tests/ui/missing-trait-bounds` -> `tests/ui/trait-bound/missing-trait-bounds`
`tests/ui/recursion_limit` -> `tests/ui/recursion/recursion_limit`
`tests/ui/version` -> `tests/ui/compile-flags`
Reorganize `tests/ui/empty`
* Move dyn-drop to dyn-keyword
* Reorganize `tests/ui/empty` into specific dirs
remove tests/ui/empty/empty-linkname.rs duplicate of tests/ui/error-codes/E0454.rs
* Move `missing-trait-bounds` to `trait-bound/missing-trait-bounds`
* bless traits/missing-trait-bounds tests
* Move `recursion_limit` to `recursion/recursion_limit`
* Move `version` to `compile-flags`
[win] Fix truncated unwinds for Arm64 Windows
Panic backtraces on ARM64 Windows are truncated because Rust's LLVM configuration sets `NoTrapAfterNoreturn = true`, which suppresses the generation of `brk #0x1` (trap) instructions after calls to `noreturn` functions. Without this trap instruction, the return address from a `noreturn` call points past the end of the calling function into an unrelated function, causing `RtlLookupFunctionEntry` to return the wrong unwind information, which terminates the stack walk prematurely.
In general, `NoTrapAfterNoreturn = true` is recommended against for Windows, since we have seen security vulnerabilities in the past where an attacker has managed to return from a noreturn function, or the function wasn't actually noereturn, resulting in executing whatever was after the call.
This change disables setting `NoTrapAfterNoreturn = true` for Windows.
Fixesrust-lang/rust#140489
Gate #![reexport_test_harness_main] properly
Address the FIXME
Removed from `issue-43106-gating-of-builtin-attrs.rs` since that is for stable attributes only.
This would be a breaking change, search of github shows it is mostly but not always used with `#![test_runner]` which is already gated correctly.
Details:
https://github.com/rust-lang/rust/issues/50297
Feel free to close this issue if you think it is not worth addressing the FIXME...
Cleanup unused diagnostic emission methods
Part of https://github.com/rust-lang/rust/issues/153099.
To remove `lint_level`, we need to remove all functions calling it. One of them is `TyCtxt::node_span_lint`, so removing it.
r? @JonathanBrouwer
refactor: move `check_align` to `parse_alignment`
Part of rust-lang/rust#153101
r? @JonathanBrouwer
PS: jonathan i'm not sure about what to do with `check_align` now
Suppress invalid suggestions in destructuring assignment
Fixesrust-lang/rust#152694
When destructuring assignment hits a type with `Drop`, the compiler was emitting two broken suggestions: `ref *&mut String::new()` (invalid syntax) and `.clone()` on a temporary (useless).
Root cause: the suggestion logic didn't know these bindings were synthetic from assign desugaring. The fix reuses the existing `AssignDesugar` detection in `BindingFinder` to collect those spans and skip both suggestions.
Do not emit ConstEvaluatable goals if type-const
Fixesrust-lang/rust#151631, fixesrust-lang/rust#151477
r? @fmease
I'd recommend reviewing commit-by-commit, the diff is less-readable to address a cyclic issue.
Fix ICE in `offset_of!` error recovery
Fixesrust-lang/rust#153236.
`offset_of!` was changed in rust-lang/rust#148151 to lower through THIR as a sum of calls to the `offset_of` intrinsic. In the error-recovery case, when no valid field indices are recorded, that lowering synthesized `0` as a `u32` even though the overall `offset_of!` expression has type `usize`.
On 64-bit targets, const-eval then tried to write a 4-byte immediate into an 8-byte destination, which caused the ICE.
Fix incorrect trailing comma suggested in no_accessible_fields
Fixesrust-lang/rust#149787
r? @estebank
I think add new field for AST for it is too heavy change for this issue, here is a trivial fix with source_map, seems enough for it.
- Hide common linker output behind `linker-info`
- Add tests
- Account for different capitalization on windows-gnu when removing
"warning" prefix
- Add some more comments
- Add macOS deployment-target test
- Ignore linker warnings from trying to statically link glibc
I don't know what's going on in `nofile-limit.rs` but I want no part
of it.
- Use a fake linker so tests are platform-independent
Fix ICEs due to incomplete typechecking on struct literals with syntax errors.
Fixesrust-lang/rust#153388.
Followup to rust-lang/rust#153227.
Today I have learned that when we don’t emit a diagnostic *specifically from typeck*, we need to call `self.infcx.set_tainted_by_errors()` to signal that the type checking is incomplete despite the lack of error.
r? fmease
Fix obtaining def_id from unresolved segment
This PR fixes ICE when trying to obtain `def_id` from an unresolved segment, part of rust-lang/rust#118212, fixesrust-lang/rust#153389.
r? @petrochenkov
Make `const_lit_matches_ty` check literal suffixes for exact type match
`const_lit_matches_ty` ignored literal suffixes. This let the `try_lower_anon_const_lit` fast path produce a mistyped `ty::Const::Value`, bypassing the type mismatch error that typeck would otherwise report.
fix(thir): Include `NoneWithError` in Enum Struct Tail Assertion
### Summary:
Fixes the ICE triggered when a syntax error appears inside an enum variant struct literal.
PR rust-lang/rust#153227 added `StructTailExpr::NoneWithError` and updated the `match base` arm in the `AdtKind::Enum` branch of `thir/cx/expr.rs`, but overlooked the `assert!(matches!(...))` guard preceding it, which still only listed `None | DefaultFields(_)`.
Closesrust-lang/rust#153390
r? @dingxiangfei2009
cc @matthiaskrgr
Do not deduce parameter attributes during CTFE
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/151842)*
Ever since rust-lang/rust#103172, `fn_abi_of_instance` might look at a function's body to deduce certain codegen optimization attributes for its indirectly-passed parameters beyond what can be determined purely from its signature (namely today `ArgAttribute::ReadOnly` and `ArgAttribute::CapturesNone`). Since rust-lang/rust#130201, looking at a function's body in this way entails generating, for any coroutine-closures, additional by-move MIR bodies (which aren't represented in the HIR)—but this requires knowing the types of their context and consequently cycles can ensue if such bodies are generated before typeck is complete (such as during CTFE).
Since they have no bearing on the evaluation result, this patch breaks a subquery out from `fn_abi_of_instance`, `fn_abi_of_instance_no_deduced_attrs`, which returns the ABI before such parameter attributes are deduced; and that new subquery is used in CTFE instead (however, since parameter attributes are only deduced in optimized builds, as a performance optimization we avoid calling the original query unless we are performing such a build).
Fixesrust-lang/rust#151748Fixesrust-lang/rust#152497
Tweak some of our internal `#[rustc_*]` TEST attributes
I think I might be the one who's used the internal TEST attrs `#[rustc_{dump_predicates,object_lifetime_default,outlives,variance}]` the most in recent times, I might even be the only one. As such I've noticed some recent-ish issues that haven't been fixed so far and which keep bothering me. Moreover I have a longstanding urge to rename several of these attributes which I couldn't contain anymore.
[`#[rustc_*]` TEST attributes](https://rustc-dev-guide.rust-lang.org/compiler-debugging.html#rustc_-test-attributes) are internal attributes that basically allow you to dump the output of specific queries for use in UI tests or for debugging purposes.
1. When some of these attributes were ported over to the new parsing API, their targets were unnecessarily restricted. I've kept encountering these incorrect "attribute cannot be used" errors all the while HIR analysis happily & correctly dumped the requested data below it. I've now relaxed their targets.
2. Since we now have target checking for the internal attributes I figured that it's unhelpful if we still intentionally crashed on invalid targets, so I've got rid of that.
3. I've always been annoyed that most of these (very old) attributes don't contain the word `dump` in their name (rendering their purpose non-obvious) and that some of their names diverge quite a bit from the corresponding query name. I've now rectified that. The new names take longer to type but it's still absolutely acceptable imo.
---
I haven't renamed all of the TEST attributes to follow the `rustc_dump_` scheme since that's quite tedious. If it's okay with you I'd like to postpone that (e.g., `rustc_{def_path,hidden_type…,layout,regions,symbol_name}`).
I've noticed that the parsers for TEST attrs are spread across `rustc_dump.rs`, `rustc_internal.rs` & `test_attrs.rs` which is a bit confusing. Since the new names are prefixed with `rustc_dump_` I've moved their parsers into `rustc_dump.rs` but of course they are still TEST attrs. IIRC, `test_attrs.rs` also contains non-`rustc_`-TEST attrs, so we can't just merge these two files. I guess that'll sort itself out in the future when I tackle the other internal TEST attrs.
r\? Jana || Jonathan
Abort after `representability` errors
Doing so results in better error messages and makes the code a bit simpler. Details in individual commits.
r? @oli-obk
Matthias Krüger