-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
rustc: factor out most of hir::def::Def's variants into DefKind, and rename to Res. #60462
Conversation
☔ The latest upstream changes (presumably #60460) made this pull request unmergeable. Please resolve the merge conflicts. |
@@ -1104,7 +1124,7 @@ impl ModuleOrUniformRoot<'_> { | |||
fn same_def(lhs: Self, rhs: Self) -> bool { | |||
match (lhs, rhs) { | |||
(ModuleOrUniformRoot::Module(lhs), | |||
ModuleOrUniformRoot::Module(rhs)) => lhs.def() == rhs.def(), | |||
ModuleOrUniformRoot::Module(rhs)) => lhs.def_id() == rhs.def_id(), |
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.
just to confirm, this change is ok, because the DefKind
would be the same if the DefId
is the same?
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.
Yes, DefKind
s must be the same for same DefId
s.
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.
Especially since this is a Module
, so a mod
/enum
/trait
, which don't even have the potential ambiguity that constructors can.
Node::Ctor(variant_data) => { | ||
// FIXME(eddyb) is this even possible, if we have a `Node::Ctor`? | ||
if variant_data.ctor_hir_id().is_none() { |
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.
Insert an assert to find out?
@@ -310,14 +310,14 @@ impl<'hir> Map<'hir> { | |||
self.definitions.as_local_node_id(def_id.to_def_id()).unwrap() | |||
} | |||
|
|||
pub fn describe_def(&self, node_id: NodeId) -> Option<Def> { | |||
fn def_kind(&self, node_id: NodeId) -> Option<DefKind> { |
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 was surprised that this worked and users of describe_def
never needed the DefId
-less variants, but if it's called only from a DefId
-based query, then it's understandable.
r=me after rebase |
c4c23c9
to
393c8bc
Compare
@bors r=petrochenkov |
📌 Commit 393c8bc24885671ebde87a74ca8d651a79f9bd23 has been approved by |
☔ The latest upstream changes (presumably #60510) made this pull request unmergeable. Please resolve the merge conflicts. |
393c8bc
to
ff174fe
Compare
@bors r=petrochenkov |
📌 Commit ff174fe has been approved by |
@bors p=100 (this bitrots almost instantly, should be merged before the next rollup) |
rustc: factor out most of hir::def::Def's variants into DefKind, and rename to Res. The first two commits are about introducing `DefKind`, both to simplify/orthogonalize `hir::def::Def`, and to allow reasoning about the kind of a definition without dealing with the redundant `DefId`. (There are likely more changes to be made, such as adding enough `DefKind` variants for `tcx.def_kind(def_id)` to return just `DefKind`, not `Option<DefKind>`, but this is pretty big as-is) The third commit frees up the `Def` name (which we may want to use in the future for "definitions", in the sense of "entities with a `DefId`") by renaming `hir::def::Def` to `Res` ("resolution"). IMO this fits, as it represents all the possible name resolution results, not just "definitions (with a `DefId`)". Quick examples: ```rust // Before: if tcx.describe_def(def_id) == Some(Def::Struct(def_id)) {...} if let Def::Struct(def_id) = path.def {...} ``` ```rust // After: if tcx.def_kind(def_id) == Some(DefKind::Struct) {...} if let Res::Def(DefKind::Struct, def_id) = path.res {...} ``` r? @petrochenkov cc @rust-lang/compiler
☀️ Test successful - checks-travis, status-appveyor |
📣 Toolstate changed by #60462! Tested on commit 13fde05. 💔 clippy-driver on windows: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk @phansch, @rust-lang/infra). |
Tested on commit rust-lang/rust@13fde05. Direct link to PR: <rust-lang/rust#60462> 💔 clippy-driver on windows: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk @phansch, @rust-lang/infra). 💔 clippy-driver on linux: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk @phansch, @rust-lang/infra). 💔 miri on windows: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra). 💔 miri on linux: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra). 💔 rls on windows: test-fail → build-fail (cc @Xanewok, @rust-lang/infra). 💔 rls on linux: test-fail → build-fail (cc @Xanewok, @rust-lang/infra).
Rustup to rustc 1.36.0-nightly (13fde05 2019-05-03) Trying to deal with changes from rust-lang/rust#60462 Moved from #4060 so everyone can collab on the rustup branch.
rustc: collapse relevant DefPathData variants into {Type,Value,Macro,Lifetime}Ns. `DefPathData` was meant to disambiguate within each namespace, but over the years, that purpose was overlooked, and it started to serve a double-role as a sort of `DefKind` (which #60462 properly adds). Now, we can go back to *only* categorizing namespaces (at least for the variants with names in them). r? @petrochenkov or @nikomatsakis cc @michaelwoerister
The first two commits are about introducing
DefKind
, both to simplify/orthogonalizehir::def::Def
, and to allow reasoning about the kind of a definition without dealing with the redundantDefId
.(There are likely more changes to be made, such as adding enough
DefKind
variants fortcx.def_kind(def_id)
to return justDefKind
, notOption<DefKind>
, but this is pretty big as-is)The third commit frees up the
Def
name (which we may want to use in the future for "definitions", in the sense of "entities with aDefId
") by renaminghir::def::Def
toRes
("resolution").IMO this fits, as it represents all the possible name resolution results, not just "definitions (with a
DefId
)".Quick examples:
r? @petrochenkov cc @rust-lang/compiler