Separate `DefId`s for variants and their constructors by davidtwco · Pull Request #59382 · rust-lang/rust

davidtwco · 2019-03-23T11:54:32Z

Part of #44109. Split off from #59376. See Zulip topic for previous discussion.

petrochenkov · 2019-03-23T22:05:42Z

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.
I'll hopefully continue and finish making these changes tomorrow.

petrochenkov · 2019-03-23T22:12:17Z

Any uses of the is_struct/is_tuple/is_unit methods are suspicious (as you could notice, !is_struct was usually used as has_ctor).
(Exhaustive) matching should generally be used instead.
Some code in derive machinery still needs this, but that's because it's very legacy.

Getting from VariantDef to its AdtDef is an uncommon operation, so it's better to remove parent_did from it + the optional DefId introduced some complexity/confusion that wasn't useful in practice.

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.

petrochenkov · 2019-03-24T15:57:59Z

I'll hopefully continue and finish making these changes tomorrow.

Done.

One remaining issue is that Node::Ctor should not contain CtorOf if possible.
CtorOf can be determined by looking at the node's parent in few places where it makes difference.
I tried to do that in petrochenkov@63edbb5, but it turned out that variant ctors and variants themselves are not always connected by the parent-child relation (variant is not a variant ctor's parent), and I didn't investigate how to fix that.

After the Node::Ctor is done, it will be better for CtorOf to live in def.rs together with CtorKind.
(And one more thing that annoys me unproportionally is that in Ctor(hir::CtorOf, DefId, CtorKind) the "secondary" thing (CtorOf) is placed before the "primary" thing (DefId), I'd personally change it to Ctor(DefId, CtorOf, CtorKind) or something.)

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.

davidtwco · 2019-03-24T18:27:04Z

Thanks for all the changes.

One remaining issue is that Node::Ctor should not contain CtorOf if possible.
CtorOf can be determined by looking at the node's parent in few places where it makes difference.
I tried to do that in petrochenkov/rust@63edbb5, but it turned out that variant ctors and variants themselves are not always connected by the parent-child relation (variant is not a variant ctor's parent), and I didn't investigate how to fix that.

I've fixed this. Your patch was pretty much there, but (the misleadingly named) get_parent function was returning a Node::Item as it finds the next parent that is an item, so I used get_parent_node and then it just worked.

After the Node::Ctor is done, it will be better for CtorOf to live in def.rs together with CtorKind.
(And one more thing that annoys me unproportionally is that in Ctor(hir::CtorOf, DefId, CtorKind) the "secondary" thing (CtorOf) is placed before the "primary" thing (DefId), I'd personally change it to Ctor(DefId, CtorOf, CtorKind) or something.)

Fixed both of these.

petrochenkov · 2019-03-24T20:59:06Z

Thanks.
3.5 years in the making!
@bors r+

bors · 2019-03-24T20:59:07Z

📌 Commit 23cae1d has been approved by petrochenkov

petrochenkov · 2019-03-24T21:00:09Z

@bors p=1
(The changes are somewhat conflict-prone and unblock other work.)

bors · 2019-03-24T21:27:04Z

⌛ Testing commit 23cae1d with merge 3752b3d...

@petrochenkov

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

bors · 2019-03-25T00:28:51Z

☀️ Test successful - checks-travis, status-appveyor
Approved by: petrochenkov
Pushing 3752b3d to master...

RalfJung · 2019-08-07T09:26:20Z

 pub ctor_kind: CtorKind,
+ /// Flags of the variant (e.g. is field list non-exhaustive)?
 flags: VariantFlags,
+ /// Recovered?


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. :)

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.

rust-highfive assigned petrochenkov Mar 23, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 23, 2019

davidtwco mentioned this pull request Mar 23, 2019
RFC 2008: Enum Variants #59376
Merged

This comment has been minimized.
Sign in to view

davidtwco force-pushed the rfc-2008-refactoring branch from 9196e73 to 184037aCompare March 23, 2019 20:33

petrochenkov force-pushed the rfc-2008-refactoring branch from 184037a to 57f1254Compare March 23, 2019 22:03

petrochenkov changed the title ~~RFC 2008: Refactoring~~Separated DefIds for variants and their constructorsMar 23, 2019

petrochenkov changed the title ~~Separated DefIds for variants and their constructors~~Separate DefIds for variants and their constructorsMar 23, 2019

davidtwcoand others added 2 commits March 24, 2019 12:10

Remove methods is_struct/is_tuple/is_unit from VariantData
c667c2f

petrochenkov force-pushed the rfc-2008-refactoring branch from 57f1254 to 3ca03b3Compare March 24, 2019 09:36

Remove VariantDef::parent_did
7f5a8dc

petrochenkov force-pushed the rfc-2008-refactoring branch 2 times, most recently from 95cf143 to 3fe5b1dCompare March 24, 2019 14:21

petrochenkov added 3 commits March 24, 2019 17:36

Slightly more uniform treatment of struct and variant constructors
5bcf9f4

Merge DefPathData::VariantCtor and DefPathData::StructCtor
2cbc25e

Revert changes to creation of fictive constructors for struct variants
782a6de

petrochenkov force-pushed the rfc-2008-refactoring branch from 3fe5b1d to 782a6deCompare March 24, 2019 15:48

petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 24, 2019

davidtwco added 3 commits March 24, 2019 18:21

Remove CtorOf from Node::Ctor.
db4770f
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.

Move CtorOf into hir::def.
88f8f07
This commit moves the definition of `CtorOf` from `rustc::hir` to `rustc::hir::def` and adds imports wherever it is used.

Re-order fields in Def::Ctor.
23cae1d
This commit moves the `DefId` field of `Def::Ctor` to be the first field.

davidtwco added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 24, 2019

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 24, 2019

bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 25, 2019

bors merged commit 23cae1d into rust-lang:masterMar 25, 2019

This was referenced Mar 25, 2019
HirIdification: rework Map #59042
Merged
Enable NLL migrate mode on the 2015 edition #59114
Merged
Provide suggestion when using field access instead of path #59267
Merged
[Step 2] Implement "small substs optimization" for substs of length 1 #59312
Closed

davidtwco deleted the rfc-2008-refactoring branch March 29, 2019 17:27

davidtwco mentioned this pull request May 13, 2019
Use a different DefId for the Def::Variant and Def::VariantCtor #59131
Closed

RalfJung reviewed Aug 7, 2019
View reviewed changes

Navigation Menu

Uh oh!

Uh oh!

Separate `DefId`s for variants and their constructors - #59382

Separate `DefId`s for variants and their constructors#59382
bors merged 9 commits into
rust-lang:masterfrom
davidtwco:rfc-2008-refactoring

davidtwco commented Mar 23, 2019

Uh oh!

This comment has been minimized.

petrochenkov commented Mar 23, 2019

Uh oh!

petrochenkov commented Mar 23, 2019•
edited
Loading

Uh oh!

petrochenkov commented Mar 24, 2019

Uh oh!

davidtwco commented Mar 24, 2019

Uh oh!

petrochenkov commented Mar 24, 2019

Uh oh!

bors commented Mar 24, 2019

Uh oh!

petrochenkov commented Mar 24, 2019

Uh oh!

bors commented Mar 24, 2019

Uh oh!

bors commented Mar 25, 2019

Uh oh!

RalfJungAug 7, 2019

Uh oh!

davidtwcoAug 7, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

davidtwco commented Mar 23, 2019

Uh oh!

This comment has been minimized.

petrochenkov commented Mar 23, 2019

Uh oh!

petrochenkov commented Mar 23, 2019• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petrochenkov commented Mar 24, 2019

Uh oh!

davidtwco commented Mar 24, 2019

Uh oh!

petrochenkov commented Mar 24, 2019

Uh oh!

bors commented Mar 24, 2019

Uh oh!

petrochenkov commented Mar 24, 2019

Uh oh!

bors commented Mar 24, 2019

Uh oh!

bors commented Mar 25, 2019

Uh oh!

RalfJungAug 7, 2019

Choose a reason for hiding this comment

Uh oh!

davidtwcoAug 7, 2019

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

petrochenkov commented Mar 23, 2019•
edited
Loading