-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove unused adt-def insertion by constructor DefIndex #40696
Conversation
cc #40614 |
I can confirm, this is not necessary now. This "constructor insertion" was done in two places - librustc_metadata/decoder.rs and librustc_typeck/collect.rs, could you make sure both are removed? |
@petrochenkov Was that the one you were thinking of? |
📌 Commit 239da92 has been approved by |
🔒 Merge conflict |
239da92
to
873248d
Compare
I've rebased this branch due to a submodule conflict that invalidated many PRs. @bors r=petrochenkov |
📌 Commit 873248d has been approved by |
…, r=petrochenkov Remove unused adt-def insertion by constructor DefIndex It looks to me like ADT definitions weren't being looked up by constructor id, and a test run supports my theory. In any case, I'm not sure it would have worked in its current configuration. If I understand correctly, the `adt_def` map entry from constructor id -> adt def would only be present after a successful call to `queries::adt_def::get` with the proper ADT `DefIndex`. Trying to look up an adt_def by the constructor index prior to a successful lookup by ADT index would fail since `item.kind` would be `EntryKind::Fn` (for the constructor function) and so would trigger the `bug!`. r? @nikomatsakis
It looks to me like ADT definitions weren't being looked up by constructor id, and a test run supports my theory.
In any case, I'm not sure it would have worked in its current configuration. If I understand correctly, the
adt_def
map entry from constructor id -> adt def would only be present after a successful call toqueries::adt_def::get
with the proper ADTDefIndex
. Trying to look up an adt_def by the constructor index prior to a successful lookup by ADT index would fail sinceitem.kind
would beEntryKind::Fn
(for the constructor function) and so would trigger thebug!
.r? @nikomatsakis