-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Separate DefId
s for variants and their constructors
#59382
Conversation
This comment has been minimized.
This comment has been minimized.
9196e73
to
184037a
Compare
184037a
to
57f1254
Compare
I reviewed the PR and had comments, but many of them required some experimentation, so I basically started tweaking the code on top of this PR. |
DefId
s for variants and their constructors
DefId
s for variants and their constructorsDefId
s for variants and their constructors
Any uses of the is_struct/is_tuple/is_unit methods are suspicious (as you could notice, Getting from |
This commit makes two changes - separating the `NodeId` that identifies an enum variant from the `NodeId` that identifies the variant's constructor; and no longer creating a `NodeId` for `Struct`-style enum variants and structs. Separation of the variant id and variant constructor id will allow the rest of RFC 2008 to be implemented by lowering the visibility of the variant's constructor without lowering the visbility of the variant itself. No longer creating a `NodeId` for `Struct`-style enum variants and structs mostly simplifies logic as previously this `NodeId` wasn't used. There were various cases where the `NodeId` wouldn't be used unless there was an unit or tuple struct or enum variant but not all uses of this `NodeId` had that condition, by removing this `NodeId`, this must be explicitly dealt with. This change mostly applied cleanly, but there were one or two cases in name resolution and one case in type check where the existing logic required a id for `Struct`-style enum variants and structs.
57f1254
to
3ca03b3
Compare
95cf143
to
3fe5b1d
Compare
3fe5b1d
to
782a6de
Compare
Done. One remaining issue is that After the |
This commit removes `CtorOf` from `Node::Ctor` as the parent of the constructor can be determined by looking at the node's parent in the few places where knowing this is necessary.
This commit moves the definition of `CtorOf` from `rustc::hir` to `rustc::hir::def` and adds imports wherever it is used.
This commit moves the `DefId` field of `Def::Ctor` to be the first field.
Thanks for all the changes.
I've fixed this. Your patch was pretty much there, but (the misleadingly named)
Fixed both of these. |
Thanks. |
📌 Commit 23cae1d has been approved by |
@bors p=1 |
Separate `DefId`s for variants and their constructors Part of #44109. Split off from #59376. See [Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rfc-2008/near/132663140) for previous discussion. r? @petrochenkov
☀️ Test successful - checks-travis, status-appveyor |
flags: VariantFlags, | ||
/// Recovered? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is the most redundant doc-comment I have ever seen.^^ It explains literally nothing...
If you have a one-sentence description of what this field does, I can add it in #63346. Or maybe it is easier for you to make a PR yourself. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that this comment isn't particularly useful. This PR was a while ago, I assume I just wanted to add some comment on each field as I was changing the type - I'm afraid I don't know what the recovered
field is used for.
Part of #44109. Split off from #59376. See Zulip topic for previous discussion.
r? @petrochenkov