resolve: Factor out and document the glob binding overwriting logic
Also, avoid creating fresh name declarations and overwriting declarations in modules to update some fields in `DeclData`, when possible.
Instead, change the fields directly in `DeclData` using cells.
Unblocks https://github.com/rust-lang/rust/pull/149195.
67ea84d erroneously added this special-case when introducing `DesugaringKind::WhileLoop`.
It had the unintended effect of emitting erroneous diagnostics in certain `while` blocks.
Since yesterday, the LLVM `main` branch should have working `f16` on all
platforms that Rust supports; this will be LLVM version 22, so update
how `cfg(target_has_reliable_f16)` is set to reflect this.
Within the rust-lang organization, this currently has no effect. The
goal is to start catching problems as early as possible in external CI
that runs top-of-tree rust against top-of-tree LLVM, and once testing
for the rust-lang bump to LLVM 22 starts. Hopefully this will mean that
we can fix any problems that show up before the bump actually happens,
meaning `f16` will be about ready for stabilization at that point (with
some considerations for the GCC patch at [1] propagating).
References:
* 919021b0df
* 054ee2f870
* db26ce5c55
* 549d7c4f35
* 4903c6260c
[1]: 8b6a18ecaf
Handling for inherent associated consts is missing elsewhere, remove so it can be handled later in that handling.
Diagnostic not always be emitted on associated constant
Add a test case and Fix for a different ICE I encountered.
I noticed when trying various permuations of the test case code to see if I could find anymore ICEs. I did, but not one that I expected. So in the instances of the a named const not having any args, insantiate it directly. Since it is likely an inherent assocaiated const.
Added tests.
Centralize the is_type_const() logic.
I also noticed basically the exact same check in other part the code.
Const blocks can't be a type_const, therefore this check is uneeded.
Fix comment spelling error.
get_all_attrs is not valid to call for all DefIds it seems.
Make sure that if the type is omitted for a type_const that we don't ICE.
Co-Authored-By: Boxy <rust@boxyuwu.dev>
Fix for ICE: eii: fn / macro rules None in find_attr()
Closesrust-lang/rust#149981
This used to ICE:
```rust
macro_rules! foo_impl {}
#[eii]
fn foo_impl() {}
```
`#[eii]` generates a macro (called `foo_impl`) and a default impl. So the partial expansion used to roughly look like the following:
```rust
macro_rules! foo_impl {} // actually resolves here
extern "Rust" {
fn foo_impl();
}
#[eii_extern_target(foo_impl)]
macro foo_impl {
() => {};
}
const _: () = {
#[implements_eii(foo_impl)] // assumed to name resolve to the macro v2 above
fn foo_impl() {}
};
```
Now, shadowing rules for macrov2 and macrov1 are super weird! Take a look at this: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=23f21421921360478b0ec0276711ad36
So instead of resolving to the macrov2, we resolve the macrov1 named the same thing.
A regression test was added to this, and some span_delayed_bugs were added to make sure we catch this in the right places. But that didn't fix the root cause.
To make sure this simply cannot happen again, I made it so that we don't even need to do a name resolution for the default. In other words, the new partial expansion looks more like:
```rust
macro_rules! foo_impl {}
extern "Rust" {
fn foo_impl(); // resolves to here now!!!
}
#[eii_extern_target(foo_impl)]
macro foo_impl {
() => {};
}
const _: () = {
#[implements_eii(known_extern_target=foo_impl)] // still name resolved, but directly to the foreign function.
fn foo_impl() {}
};
```
The reason this helps is that name resolution for non-macros is much more predictable. It's not possible to have two functions like that with the same name in scope.
We used to key externally implementable items off of the defid of the macro, but now the unique identifier is the foreign function's defid which seems much more sane.
Finally, I lied a tiny bit because the above partial expansion doesn't actually work.
```rust
extern "Rust" {
fn foo_impl(); // not to here
}
const _: () = {
#[implements_eii(known_extern_target=foo_impl)] // actually resolves to this function itself
fn foo_impl() {} // <--- so to here
};
```
So the last few commits change the expansion to actually be this:
```rust
macro_rules! foo_impl {}
extern "Rust" {
fn foo_impl(); // resolves to here now!!!
}
#[eii_extern_target(foo_impl)]
macro foo_impl {
() => {};
}
const _: () = {
mod dflt { // necessary, otherwise `super` doesn't work
use super::*;
#[implements_eii(known_extern_target=super::foo_impl)] // now resolves to outside the `dflt` module, so the foreign item.
fn foo_impl() {}
}
};
```
I apologize to whoever needs to review this, this is very subtle and I hope this makes it clear enough 😭.
Fix ICE in inline always warning emission.
The calls to `def_path_str` were outside the decorate callback in `node_span_lint` which caused an ICE when the warning was an allowed warning due to the call to `def_path_str` being executed but the warning not actually being emitted.
r? @davidtwco
Add tracking issue for `feature(multiple_supertrait_upcastable)`
Move feature(multiple_supertrait_upcastable) to the actual feature gates section (from the internal feature gates section) and give it a tracking issue.
Tracking issue: rust-lang/rust#150833
Fixes https://github.com/rust-lang/rust/issues/150773
This feature is for the `multiple_supertrait_upcastable` lint, which was added as `unstable` without a tracking issue, but was placed in the internal feature gates section. This PR moves its listing to the actual feature gates section and gives it a tracking issue.
If the lint is intended to stay internal-only, then this can be changed to instead mark it as `internal` (and maybe close the tracking issue).
make attrs actually use `Target::GenericParam`
currently attributes lower `GenericParam` -> `Target::Param` this PR fixes this, so that `GenericParam` is lowered to `Target::GenericParam`
r? @JonathanBrouwer
Clarify `MoveData::init_loc_map`.
Change the `SmallVec` size from 4 to 1, because that's sufficient in the vast majority of cases. (This doesn't affect performance in practice, so it's more of a code clarity change than a performance change.)
r? @cjgillot
Finish transition from `semitransparent` to `semiopaque` for `rustc_macro_transparency`
Since it's a bit annoying to have different names for the same thing.
My understanding is that this is just internal stuff that is not part of any public API even tough rust-analyzer knows about it.
Continuation of
- https://github.com/rust-lang/rust/pull/139084.
Discovered while investigating
- https://github.com/rust-lang/rust/issues/150514
fix `Expr::can_have_side_effects` for `[x; N]` style array literal and binary expressions
AFAIK `[0; 3]` is basically a syntax sugar for `[0, 0, 0]` so it should return whether the repeat's element can have side effects, like what it does on arrays.
And it seems that the rule for unary operators and indexings can be applied to binary operators as well.
Add a rustc intrinsic `amdgpu_dispatch_ptr` to access the kernel
dispatch packet on amdgpu.
The HSA kernel dispatch packet contains important information like the
launch size and workgroup size.
The Rust intrinsic lowers to the `llvm.amdgcn.dispatch.ptr` LLVM
intrinsic, which returns a `ptr addrspace(4)`, plus an addrspacecast to
`addrspace(0)`, so it can be returned as a Rust reference.
The returned pointer/reference is valid for the whole program lifetime,
and is therefore `'static`.
The return type of the intrinsic (`*const ()`) does not mention the
struct so that rustc does not need to know the exact struct type.
An alternative would be to define the struct as lang item or add a
generic argument to the function.
Short version:
```rust
#[cfg(target_arch = "amdgpu")]
pub fn amdgpu_dispatch_ptr() -> *const ();
```
The most important change here relates to type folding: we now check the
flags up front, instead of doing it in `inner_fold_ty` after checking
the cache and doing a match. This is a small perf win, and matches other
similar folders (e.g. `CanonicalInstantiator`).
Likewise for const folding, we now check the flags first. (There is no
cache for const folding.)
Elsewhere we don't check flags before folding a predicate (unnecessary,
because `fold_predicate` already checks the flags itself before doing
anything else), and invert the flag checks in a couple of methods to
match the standard order.
Query associated_item_def_ids when needed
This commit moves a query to `associated_item_defs` from above an error condition caused independently of it to below it.
It looks generally cleaner and might potentially save some runtime in case the error condition is met, rendering `items` to be left unused, yet still queried.
Store defids instead of symbol names in the aliases list
I was honestly surprised this worked in the past. This causes a cycle error since we now compute a symbol name in codegen_attrs, and then compute codegen attrs when we try to get the symbol name.
It only worked when there weren't any codegen attributes to begin with, causing symbol name computation to skip the call to codegen_attrs.
Like this we won't have the same problem.
r? @bjorn3
Update `literal-escaper` version to `0.0.7`
It removes the `std` dependency for this crate (which doesn't change anything for rustc 😄 ).
cc @bjorn3
r? @Urgau
Deprecated doc intra link
fixes https://github.com/rust-lang/rust/issues/98342
r? @GuillaumeGomez
Renders intra-doc links in the note text of the `#[deprecated]` attribute. It is quite natural to suggest some other function to use there. So e.g.
```rust
#[deprecated(since = "0.0.0", note = "use [`std::mem::size_of`] instead")]
```
renders as
<img width="431" height="74" alt="Screenshot from 2026-01-06 12-08-21" src="https://github.com/user-attachments/assets/8f608f08-13ee-4bbf-a631-6008058a51e2" />
When a trait parameter depends upon Sized, the error message only
referred to the full trait itself and didn't mention Sized. This makes
the failure to implement Sized explicit. It also notes when the Sized
trait bound is explicit or implicit.
This commit moves a query to `associated_item_defs` from above an error
condition caused independently of it to below it.
It looks generally cleaner and might potentially save some runtime in
case the error condition is met, rendering `items` to be left unused,
yet still queried.
