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
`fn_abi_of_instance` can look at function bodies to deduce codegen
optimization attributes (namely `ArgAttribute::ReadOnly` and
`ArgAttribute::CapturesNone`) of indirectly-passed parameters. This can
lead to cycles when performed during typeck, when such attributes are
irrelevant.
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.
diag: Suppress `.clone()` suggestion inside derive macro expansions
Derives on a packed struct with non-Copy fields generate moves whose spans point back at the original field type definitions. `suggest_cloning_inner()` then proposes inserting `.clone()` at those locations, producing nonsensical output like `String.clone()` in the struct definition.
closerust-lang/rust#153126
Improve irrefutable let-else lint wording
Update the `irrefutable_let_patterns` wording for let-else to better reflect that the `else` clause is unreachable when the LHS pattern always matches.
Closesrust-lang/rust#152938
x86: reserve `bl` and `bh` registers to match `rbx`
`bl` and `bh` need to be explicitly marked as reserved, as they are sub-registers of `rbx`, which is reserved by LLVM.
Discovered this while trying to run Graviola through Cranelift, which was becoming corrupted due to the register allocator assigning `bl`: https://github.com/rust-lang/rustc_codegen_cranelift/pull/1629
cc: @bjorn3
Currently, `Representability::from_cycle_error` prints an "infinite
size" error and then returns `Representability::Infinite`, which lets
analysis continue. This commit changes it so it just aborts after
printing the error. This has two benefits.
First, the error messages are better. The error messages we get after
continuing are mostly bad -- we usually get another cycle error, e.g.
about drop checking or layout, which is not much use to the user, and
then abort after that. The only exception is `issue-105231.rs` where a
"conflicting implementations" error is now omitted, but there are three
other errors before that one so it's no great loss.
Second, it allows some simplifications: see the next commit.
MGCA: fix type error handling for const array and tuple lowering logic
It's a simple fix; just needed to handle Ty::Error in `lower_const_arg_array` and `lower_const_arg_tup`
Fixesrust-lang/rust#153254
r? @fmease
Replace CodegenResults with CompiledModules
This is already CodegenResults without CrateInfo. The driver can calculate the CrateInfo and pass it by-ref to the backend. Using CompiledModules makes it a bit easier to move some other things out of the backend as will be necessary for moving LTO to the link phase.
Helps with https://github.com/rust-lang/compiler-team/issues/908
Parse `impl` restrictions
This PR implements the parsing logic for `impl` restrictions (e.g., `pub impl(crate) trait Foo {}`) as proposed in [RFC 3323](https://rust-lang.github.io/rfcs/3323-restrictions.html).
As the first step of the RFC implementation, this PR focuses strictly on the parsing phase. The new syntax is guarded by the `#![feature(impl_restriction)]` feature gate.
This implementation basically follows the pattern used in rust-lang/rust#141754.
r? @jhpratt
Jonathan Brouwer