rust/compiler/rustc_resolve/src/lib.rs, branch 1.84.1

Remove `Resolver::empty_disambiguator`.

2024-11-14T01:08:20+00:00

It was added in #115367 for anonymous ADTs. Those changes were then reverted in #131045, but `empty_disambiguator` was left behind, perhaps by mistake. It seems to be unnecessary.

Tweak a `resolutions` loop.

2024-11-14T00:35:26+00:00

In this case field access is more concise and easier to read than destructuring, and it matches how other similar loops are done elsewhere.

fix clippy::clone_on_ref_ptr for compiler

2024-10-28T15:05:08+00:00

Stop relying on hashmap iteration for unused macro rules arms

2024-10-20T07:12:52+00:00

rustdoc: prevent ctors from resolving

2024-10-04T05:01:23+00:00

Handle `rustc_metadata` cases of `rustc::potential_query_instability` lint

2024-10-03T05:38:51+00:00

Handle `rustc-hir-analysis` cases of `rustc::potential_query_instability` lint

2024-10-02T05:28:45+00:00

Reformat using the new identifier sorting from rustfmt

2024-09-22T23:11:29+00:00

Handle macro calls in anon const def creation take 2

2024-09-21T21:17:18+00:00

Auto merge of #129137 - camelid:lazy-def-macro-const, r=BoxyUwU

2024-09-13T01:10:51+00:00

Fix anon const def-creation when macros are involved Fixes #128016. Ever since #125915, some `ast::AnonConst`s turn into `hir::ConstArgKind::Path`s, which don't have associated `DefId`s. To deal with the fact that we don't have resolution information in `DefCollector`, we decided to implement a process where if the anon const *appeared* to be trivial (i.e., `N` or `{ N }`), we would avoid creating a def for it in `DefCollector`. If later, in AST lowering, we realized it turned out to be a unit struct literal, or we were lowering it to something that didn't use `hir::ConstArg`, we'd create its def there. However, let's say we have a macro `m!()` that expands to a reference to a free constant `FOO`. If we use `m!()` in the body of an anon const (e.g., `Foo<{ m!() }>`), then in def collection, it appears to be a nontrivial anon const and we create a def. But the macro expands to something that looks like a trivial const arg, but is not, so in AST lowering we "fix" the mistake we assumed def collection made and create a def for it. This causes a duplicate definition ICE. The long-term fix for this is to delay the creation of defs for all expression-like nodes until AST lowering (see #128844 for an incomplete attempt at this). This would avoid issues like this one that are caused by hacky workarounds. However, doing this uncovers a pre-existing bug with opaque types that is quite involved to fix (see #129023). In the meantime, this PR fixes the bug by delaying def creation for anon consts whose bodies are macro invocations until after we expand the macro and know what is inside it. This is accomplished by adding information to create the anon const's def to the data in `Resolver.invocation_parents`. r? `@BoxyUwU`