Index expressions rendered the index: subexpression as the id, instea…
…d of actually showing the content of the subexpression
This meant the content of the subexpression was completely missing from tree view (as the id did not reference anything)
Feature gate for defaulted associated type_consts with associated_type_defaults
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/152385)*
This PR for issue rust-lang/rust#130288 extends a feature gate that was already present for defaulted associated types to defaulted type consts under associated_type_defaults.
Code added:
```
if ctxt == AssocCtxt::Trait && rhs.is_some() {
gate!(
&self,
associated_type_defaults,
i.span,
"associated type defaults are unstable"
);
}
```
Error produced:
```
error[E0658]: associated type defaults are unstable
--> $DIR/type-const-associated-default.rs:4:5
|
LL | type const N: usize = 10;
| ^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #29661 <https://github.com/rust-lang/rust/issues/29661> for more information
= help: add `#![feature(associated_type_defaults)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
warning: the feature `min_generic_const_args` is incomplete and may not be safe to use and/or cause compiler crashes
--> $DIR/type-const-associated-default.rs:1:12
|
LL | #![feature(min_generic_const_args)]
| ^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #132980 <https://github.com/rust-lang/rust/issues/132980> for more information
= note: `#[warn(incomplete_features)]` on by default
error: aborting due to 1 previous error; 1 warning emitted
For more information about this error, try `rustc --explain E0658`.
```
Thanks to @BoxyUwU for the guidance on this issue.
`rustc_queries` simplifications
Queries have two ways of specifying code snippets, in `desc` and `cache_on_disk_if` blocks. An example:
```rust
query check_liveness(key: LocalDefId) -> &'tcx rustc_index::bit_set::DenseBitSet<abi::FieldIdx> {
arena_cache
desc { |tcx| "checking liveness of variables in `{}`", tcx.def_path_str(key.to_def_id()) }
cache_on_disk_if(tcx) { tcx.is_typeck_child(key.to_def_id()) }
}
```
If you need to use `tcx` in the snippet, you can use an explicit binding. But there are multiple problems with this.
- The syntax used is different in the two snippets: `|tcx|` within the block vs. `(tcx)` outside the block. (!!)
- Bug 1: In `desc` snippets you can leave out the `|tcx|` and still use `tcx`. Several existing queries do this.
- Bug 2: In `desc` snippets you can always use `key` in the snippet to refer to the key, even if that's not the identifier used in the query head.
- Finally, you can bind `tcx` and not use it, without a warning. Several existing queries do this.
I think explicit `tcx` binding is silly. Many queries need `tcx` and this macro is already super-magical, so just making `tcx` implicitly available seems fine, rather than making the query writer jump through a little syntactic hoop. This makes both the query definitions and the proc macro simpler.
r? @petrochenkov
Start migration for `LintDiagnostic` items by adding API and migrating `LinkerOutput` lint
This is more or less the same approach as https://github.com/rust-lang/rust/pull/152811, but in a much smaller size to make it reviewable. A lot of PRs will follow though. :)
This PR creates the equivalent of `lint_level` working with `Diagnostic` and add new methods on `MultiSpan` to make it work as well (in particular because we need to copy messages/spans from one context to another).
r? @JonathanBrouwer
Remove `impl IntoQueryParam<P> for &'a P`.
`IntoQueryParam` is a trait that lets query callers be a bit sloppy with the passed-in key.
- Types similar to `DefId` will be auto-converted to `DefId`. Likewise for `LocalDefId`.
- Reference types will be auto-derefed.
The auto-conversion is genuinely useful; the auto-derefing much less so. In practice it's only used for passing `&DefId` to queries that accept `DefId`, which is an anti-pattern because `DefId` is marked with `#[rustc_pass_by_value]`.
This commit removes the auto-deref impl and makes the necessary sigil adjustments. (I generally avoid using `*` to deref manually at call sites, preferring to deref via `&` in patterns or via `*` in match expressions. Mostly because that way a single deref often covers multiple call sites.)
r? @cjgillot
fix(codegen): Use `body_codegen_attrs` For Caller In `adjust_target_feature_sig`
### Summary:
#### Problem:
Coercing a `#[target_feature]` `const fn` to a function pointer inside a `const` body triggers an ICE (debug builds only):
```rust
#[target_feature(enable = "sse2")]
const fn with_target_feature() {}
const X: () = unsafe {
let _: unsafe fn() = with_target_feature; // ICE
};
```
```text
assertion failed: def_kind.has_codegen_attrs()
unexpected `def_kind` in `codegen_fn_attrs`: Const
```
#### Root Cause:
Introduced in rust-lang/rust#135504 (2025-01-14, commit `8fee6a77394`). `adjust_target_feature_sig` unconditionally calls `codegen_fn_attrs(caller)` to get the caller's target features. `codegen_fn_attrs` requires that the `DefId` satisfies `has_codegen_attrs()`. `DefKind::Const`, `AssocConst`, and `InlineConst` do not — they have no codegen attributes by design. The debug assertion fires.
In release builds the call "worked" accidentally: `codegen_fn_attrs` on a const would reach the query machinery and happen to return empty attributes, producing a correct (but unguaranteed) result. The bug was latent until debug builds exposed it.
#### Solution:
Replace `codegen_fn_attrs(caller)` with `body_codegen_attrs(caller)`. `body_codegen_attrs` exists precisely for this case: it delegates to `codegen_fn_attrs` for function-like `DefKind`s and returns `CodegenFnAttrs::EMPTY` for const items. A const body has no target features, so returning empty is semantically correct.
Also fix the pre-existing variable name `callee_features` → `caller_features` (the variable holds the *caller*'s features, not the callee's).
### Changes:
- `compiler/rustc_middle/src/ty/context.rs`: `adjust_target_feature_sig` — use `body_codegen_attrs` for `caller`; rename `callee_features` → `caller_features`.
- `tests/ui/target-feature/const-target-feature-fn-ptr-coercion.rs`: regression test covering `Const`, `AssocConst`, and `InlineConst` caller contexts.
Fixesrust-lang/rust#152340.
reduce the amount of panics in `{TokenStream, Literal}::from_str` calls
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/147859)*
Before this PR, calling `TokenStream::from_str` or `Literal::from_str` with an invalid argument would always cause a compile error, even if the `TokenStream` is not used afterwards at all.
This PR changes this so it returns a `LexError` instead in some cases.
This is very theoretically a breaking change, but the doc comment on the impl already says
```
/// NOTE: some errors may cause panics instead of returning `LexError`. We reserve the right to
/// change these errors into `LexError`s later.
```
Fixes some cases of rust-lang/rust#58736.
Fix ICE in const eval of packed SIMD types with non-power-of-two element counts
fixesrust-lang/rust#151537
const evaluation of packed SIMD types with non-power-of-two element counts (like `Simd<_, 3>`) was hitting an ICE. the issue was in `check_simd_ptr_alignment` - it asserted that `backend_repr` must be `BackendRepr::SimdVector`, but for packed SIMD types with non-power-of-two counts the compiler uses `BackendRepr::Memory` instead (as mentioned in `rustc_abi/src/layout.rs:1511`).
was fixed by making `check_simd_ptr_alignment` accept both `BackendRepr::SimdVector` and `BackendRepr::Memory` for SIMD types. added a check to ensure we're dealing with a SIMD type, and the alignment logic works the same for both representations.
also i added a test that reproduces the original ICE.
rustc_target: callconv: powerpc64: Use the ABI set in target options instead of guessing
All PowerPC64 targets except AIX explicitly set the ABI in the target options. We can therefore stop hardcoding the ABI to be used based on the target environment or OS, except for the AIX special case.
The fallback based on endianness is kept for the sake of compatibility with custom targets.
This makes it so that big endian targets not explicitly accounted for before (powerpc64-unknown-openbsd) and targets that don't use the expected default ABI (big-endian ELFv2 Glibc targets) use the correct ABI in the calling convention code.
The second commit is a tiny change to validate the `llvm_abiname` set on PowerPC64(LE) targets. See the commit messages for details.
CC @RalfJung who pointed out the missing `llvm_abiname` validation
As currently written, these have big problems.
- `desc` and `cache_on_disk_if` modifiers use different syntaxes to
introduce `tcx`.
- `desc` is mis-implemented such that the explicit binding isn't even
necessary and the key name can be botched, as the previous two commits
showed. (It's the `let (#tcx, #key) = (tcx, key);` line that messes
things up.)
It's simpler and less error-prone to simply not require explicit `tcx`
bindings, and instead just make it implicitly available to these code
snippets.
Due to a bug they aren't actually necessary! (A few queries already take
advantage of this, probably unintentionally.) And the next commit will
remove support for explicit `tcx` bindings in favour of implicit.
Due to a bug, you can currently use `key` within the `desc` block and
it'll just work regardless of what actual key name you specified. A
subsequent commit will fix this, so let's correct the affected queries
first.
`IntoQueryParam` is a trait that lets query callers be a bit sloppy with
the passed-in key.
- Types similar to `DefId` will be auto-converted to `DefId`. Likewise
for `LocalDefId`.
- Reference types will be auto-derefed.
The auto-conversion is genuinely useful; the auto-derefing much less so.
In practice it's only used for passing `&DefId` to queries that accept
`DefId`, which is an anti-pattern because `DefId` is marked with
`#[rustc_pass_by_value]`.
This commit removes the auto-deref impl and makes the necessary sigil
adjustments. (I generally avoid using `*` to deref manually at call
sites, preferring to deref via `&` in patterns or via `*` in match
expressions. Mostly because that way a single deref often covers
multiple call sites.)
Error on attempt to construct scalable vector type
If you attempt to construct a scalable vector type rust will ICE.
E.g.:
```rust
#[rustc_scalable_vector(4)]
#[allow(non_camel_case_types)]
struct svint32_t(i32);
fn main() {
let foo = svint32_t(1);
// This will ICE
}
```
This PR adds a check that will emit an error if you attempt to use a SV constructor and a test to ensure it works.
Tighten the `!range` bounds on alignments in vtables
Right now we're only telling LLVM that they're non-zero, but alignments must be powers of two so can't be more than `isize::MAX+1`. And we actually never emit anything beyond LLVM's limit of 2²⁹, so outside of 16-bit targets the limit is that.
(Pulled out from rust-lang/rust#152867 which is starting to have too much in it.)
Expose Span for all DefIds in rustc_public
Part of https://github.com/rust-lang/project-stable-mir/issues/118
To be maximally useful, `VariantDef` and `FieldDef` should be changed to be a wrapper around `DefId` instead of holding their parent and index. I can do this change in this PR or a follow-up if it is desired. For now, I added the missing `impl Stable for DefId` in internals so you can convert from rustc internals.
Skip the `use_existential_projection_new_instead` field in the `Debug` impl
Resolves: rust-lang/rust#152807 .
Simply slap a `#derive_where[skip(Debug)]` on that field.
Support importing path-segment keyword with renaming
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/146972)*
#### Reference PR
- https://github.com/rust-lang/reference/pull/2010
- https://github.com/rust-lang/reference/pull/2136
#### Description
This PR unifies and extends the behavior of importing path-segment keywords (`crate`/`$crate`/`super`/`self`), resolving several long-standing inconsistencies.
Previously, Rust only allowed `use crate as name;` without renaming support for other path keywords. This PR enables importing these keywords with explicit renaming. And it also denies importing these keywords without renaming.
##### What's now allowed
For **`crate`** and **`$crate`**:
- `use crate as name;`
- `use crate::{self as name};`
- `use $crate as name;`
- `use $crate::{self as name};`
For **`super`** (including chained `super::super`):
- `use super as name;`
- `use super::{self as name};`
- `use super::super as name;`
- `use super::super::{self as name};`
For **`self`**:
- `use self as name;`
- `use self::{self as name};`
##### Removed error codes
Two error codes are no longer emitted:
- **E0430**: Previously emitted for duplicate `self` imports like `std::fmt::{self, self}`. The existing E0252 ("name defined multiple times") provides sufficient guidance.
- **E0431**: Previously emitted for `use {self [as name]};` and `use ::{self [as name]};`. These patterns are now allowed or denied but with new clearer errors.
- For `use {self as name};` and `use ::{self as name};` (in edition 2015), they are allowed now and equivalent to `use crate as name`;
- For `use {self};` and `use ::{self};` (in edition 2015) without renaming, they are equivalent to `use crate;`, the new clearer error suggests adding an explicit rename.
- For `use ::{self [as name]};` after edition 2015, it is equivalent to `use ${extern-prelude} [as name];`, it is denied with new errors.
##### Future
We plan to remove error [E0429](https://doc.rust-lang.org/stable/error_codes/E0429.html#error-code-e0429) and support `self` at the end of paths (https://github.com/rust-lang/rust/pull/146972#issuecomment-3719825627). This language extension and lint for redundant `::self` instead of hard error `E0429` will be landed separately in the future.
---
Fixesrust-lang/rust#29036Fixesrust-lang/rust#35612Fixesrust-lang/rust#37156Fixesrust-lang/rust#146967Fixesrust-lang/rust#149811
r? petrochenkov
Not linting irrefutable_let_patterns on let chains
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/146832)*
# Description
this PR makes the lint `irrefutable_let_patterns` not check for `let chains`,
only check for single `if let`, `while let`, and `if let guard`.
# Motivation
Since `let chains` were stabilized, the following code has become common:
```rust
fn max() -> usize { 42 }
fn main() {
if let mx = max() && mx < usize::MAX { /* */ }
}
```
This code naturally expresses "please call that function and then do something if the return value satisfies a condition".
Putting the let binding outside the if would be bad as then it remains in scope after the if, which is not the intent.
Current Output:
```bash
warning: leading irrefutable pattern in let chain
--> src/main.rs:7:8
|
7 | if let mx = max() && mx < usize::MAX {
| ^^^^^^^^^^^^^^
|
= note: this pattern will always match
= help: consider moving it outside of the construct
= note: `#[warn(irrefutable_let_patterns)]` on by default
```
Another common case is progressively destructuring a struct with enum fields, or an enum with struct variants:
```rust
struct NameOfOuterStruct {
middle: NameOfMiddleEnum,
other: (),
}
enum NameOfMiddleEnum {
Inner(NameOfInnerStruct),
Other(()),
}
struct NameOfInnerStruct {
id: u32,
}
fn test(outer: NameOfOuterStruct) {
if let NameOfOuterStruct { middle, .. } = outer
&& let NameOfMiddleEnum::Inner(inner) = middle
&& let NameOfInnerStruct { id } = inner
{
/* */
}
}
```
Current Output:
```bash
warning: leading irrefutable pattern in let chain
--> src\main.rs:17:8
|
17 | if let NameOfOuterStruct { middle, .. } = outer
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this pattern will always match
= help: consider moving it outside of the construct
= note: `#[warn(irrefutable_let_patterns)]` on by default
warning: trailing irrefutable pattern in let chain
--> src\main.rs:19:12
|
19 | && let NameOfInnerStruct { id } = inner
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this pattern will always match
= help: consider moving it into the body
```
To avoid the warning, the readability would be much worse:
```rust
fn test(outer: NameOfOuterStruct) {
if let NameOfOuterStruct {
middle: NameOfMiddleEnum::Inner(NameOfInnerStruct { id }),
..
} = outer
{
/* */
}
}
```
# related issue
* rust-lang/rust#139369
# possible questions
1. Moving the irrefutable pattern at the head of the chain out of it would cause a variable that was intended to be temporary to remain in scope, so we remove it.
However, should we keep the check for moving the irrefutable pattern at the tail into the body?
2. Should we still lint `entire chain is made up of irrefutable let`?
---
This is my first time contributing non-documentation code to Rust. If there are any irregularities, please feel free to point them out.
: )
Within `define_callbacks!`:
- Use `Key<'tcx>` where possible instead of `$($K)*`.
- Use `Value<'tcx>` where possible instead of `$V`.
In the other `define_*!` macros:
- Use `$K:ty` where possible instead of `$($K:tt)*`.
- Add comments about unused `$K` and `$V` cases.
- Add `()` key types to the special nodes in the `define_dep_nodes!`
invocation for consistency with normal queries.
It doesn't make much sense to put the query doc comments on these
structs. (The doc comments *are* put on various query functions, where
it makes more sense.)
So that all `$( ... $name ... )*` repetitions are spread across multiple
lines, even if they all fit on one line. I find this much easier to read
because the `$name` repetition is the main feature of these macros.
There are six small macros used in `define_callbacks` that all expand to
one thing if a particular query modifier is present, and to another
thing otherwise.
One of these macros looks for the `arena_cache` modifier:
- `query_if_arena`
Two of these macros look for the `return_result_from_ensure_ok`
modifier:
- `query_ensure_select`
- `ensure_ok_result`
Three of these macros look for the `separate_provide_extern` modifier:
- `local_key_if_separate_extern`
- `separate_provide_extern_decl`
- `separate_provide_extern_default`
(There is also `query_helper_param_ty!`, but it follows a different
pattern, and I will deal with it later.)
The "one thing"/"another thing" is different for every macro. For most
of them you can't see at the macro call site what the expansion will be;
you have to look at the macro definition. This is annoying.
This commit reduces the six macros into three macros:
- `if_arena_cache`
- `if_return_result_from_ensure_ok`
- `if_separate_provide_extern`
They all have the same form: they look for a modifier and then expand to
one *given* thing or the other *given* thing. You can see at the call
site the two possible expansions, which is much nicer. (Note:
`query_if_arena` already had this form.)
Ideally there would be a single macro instead of three, but I couldn't
work out a way to combine them.
resolve: do not suggest `_` for unresolved imports
Fix invalid unresolved-import suggestion when a module contains an item named `_`.
`use _` is never valid syntax, so `_` should not be suggested as a similar name.
Closesrust-lang/rust#152812
Clarify some variable names in the query proc-macro
These are some cleanups to the `rustc_macros::query`, extracted from https://github.com/rust-lang/rust/pull/152833.
r? nnethercote
Rename `DepGraphQuery` to `RetainedDepGraph`
This is a revised subset of https://github.com/rust-lang/rust/pull/152836 that only performs an internal renaming, and does not touch the `-Zquery-dep-graph` flag.
The new name and comments for `RetainedDepGraph` should hopefully do a better job of communicating that it is not used in normal compiler operation, even in incremental mode.
As far as I can tell it was introduced to allow fat LTO with
-Clinker-plugin-lto. Later a change was made to automatically disable
ThinLTO summary generation when -Clinker-plugin-lto -Clto=fat is used,
so we can safely remove it.
Stuart Cook