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

Refactoring/bugfixing around definitions for struct/variant constructors #36814

Merged
merged 8 commits into from Oct 5, 2016

Conversation

Projects
None yet
4 participants
@petrochenkov
Contributor

petrochenkov commented Sep 29, 2016

d917c36 separates definitions for struct/variant constructors living in value namespace from struct/variant type definitions.

adfb378 fixes cross-crate resolution of reexports reexporting half-items, like struct constructors without struct type or types without constructor. Such reexports can appear due to glob shadowing.
Resolution now is not affected by the order in which items and reexports are decoded from metadata (cc #31337 (comment)). try_define is not used during building reduced graph anymore.
500 lines of this PR are tests for this exotic situation, the remaining line diff count is actually negative! :)

c695d0c (and partially aabf132) moves most of pattern resolution checks from typeck to resolve (except those checking for associated items), uses the same wording for pattern resolution error messages from both typeck and resolve and makes the messages more precise.

11e3524 fixes seemingly incorrectly set NON_ZERO_SIZED attributes for struct/variant ctors in const eval.

4586fea eliminates ty::VariantKind in favor of def::CtorKind. The logic is that variant kinds are irrelevant for types, they make sense only when we deal with constructor functions/constants. Despite that VariantDefData still keeps a copy of CtorKind, but it's used only for various kinds of pretty-printing (and for storing in metadata).

aabf132 is mostly a cleanup of various impossible or improperly used definitions, and other small definition cleanups.

cc @jseyfried
r? @eddyb

@@ -123,10 +152,16 @@ impl Def {
Def::Mod(..) => "module",
Def::Static(..) => "static",
Def::Variant(..) => "variant",
Def::VariantCtor(.., CtorKind::Fn) => "tuple variant",
Def::VariantCtor(.., CtorKind::Const) => "unit variant",
Def::VariantCtor(.., CtorKind::Fictive) => "struct variant",

This comment has been minimized.

@petrochenkov

petrochenkov Sep 29, 2016

Contributor

I went with more traditional, but less precise descriptions.
Something like "variant's constructor functions" and "fictive variant constructor" would be more appropriate, but they are a bit long and not very user friendly.

@@ -130,7 +130,7 @@ fn get_aggregate_statement_index<'a, 'tcx, 'b>(start: usize,
debug!("getting variant {:?}", variant);
debug!("for adt_def {:?}", adt_def);
let variant_def = &adt_def.variants[variant];
if variant_def.kind == VariantKind::Struct {
if variant_def.ctor_kind == CtorKind::Fictive {

This comment has been minimized.

@petrochenkov

petrochenkov Sep 29, 2016

Contributor

I'm not sure why this condition is here.
All structs seem to be equivalent at this stage regardless of presence and kind of their constructor.

This comment has been minimized.

@eddyb

eddyb Sep 29, 2016

Member

Yeah this looks like it can only limit the optimization, it should probably be removed. cc @pcwalton

pub name: ast::Name, // The name of the target.
pub def_id: DefId, // The definition of the target.
pub name: ast::Name, // The name of the target.
pub def: Def, // The definition of the target.

This comment has been minimized.

@petrochenkov

petrochenkov Sep 29, 2016

Contributor

DefId alone is not enough for describing a reexport precisely.
Variants can be exported separately in type and value namespaces, but have a single DefId (and NodeId).

@@ -122,7 +122,6 @@ pub struct ExternCrate {
/// can be accessed.
pub trait CrateStore<'tcx> {
// item info
fn describe_def(&self, def: DefId) -> Option<Def>;

This comment has been minimized.

@eddyb

eddyb Sep 29, 2016

Member

Whoa, how is this even possible?! Even if you managed to remove uses of it, this is important for other things.
E.g. I was telling @solson about describe_def being usable for telling apart static and static mut.
And I've used it in an upcoming PR to replace is_extern_item.

This comment has been minimized.

@petrochenkov

petrochenkov Sep 29, 2016

Contributor

Oh, well. I'll return it back then.
It was completely replaced by Defs in Exports returned by item_children.
describe_def in its removed form has a catch though - variant ctors "decay" into variant types because they share DefId. item_children adjust the children lists to correctly fill both namespaces.

This comment has been minimized.

@eddyb

eddyb Sep 29, 2016

Member

Right, I think the correct thing here is to split the DefId if we need them separate.

@petrochenkov

This comment has been minimized.

Contributor

petrochenkov commented Sep 29, 2016

@nrc, could you look at the changes in save_analysis in aabf132? I'm not sure if it's covered by tests or not.

let ctor_kind = self.get_ctor_kind(child_index);
let ctor_def = Def::VariantCtor(def_id, ctor_kind);
callback(def::Export { def: ctor_def, name: name });
}

This comment has been minimized.

@eddyb

eddyb Sep 29, 2016

Member

Am I understanding correctly that Def::Variant is supposed to be solely in the type namespace?
If we really need this distinction, shouldn't they have different DefId's?

This comment has been minimized.

@petrochenkov

petrochenkov Sep 29, 2016

Contributor

If we really need this distinction, shouldn't they have different DefId's?

They should! I suspect it will be a precondition for implementing variant types.
It's a massive refactoring though, a lot of code needs to be adjusted to use new ids.

This comment has been minimized.

@petrochenkov

petrochenkov Sep 29, 2016

Contributor

I actually tried to do this separation the last autumn, a year ago (as a part of #28816), but wasn't able to build even libcore after that.
So, maybe the refactoring wasn't actually so massive and it was just my lack of experience.

@eddyb

This comment has been minimized.

Member

eddyb commented Sep 29, 2016

cc @nikomatsakis Do you think it's worth to have one DefId for the variant itself and one for the constructor of that variant?

@@ -334,10 +330,14 @@ impl<'l, 'tcx: 'l, 'll, D: Dump + 'll> DumpVisitor<'l, 'tcx, 'll, D> {
scope: scope
}.lower(self.tcx));
}
Def::Local(..) |
Def::Upvar(..) |

This comment has been minimized.

@nrc

nrc Sep 29, 2016

Member

Why don't you expect to lookup locals here?

This comment has been minimized.

@petrochenkov

petrochenkov Sep 29, 2016

Contributor

The function is used only on exports, so everything non-exportable (locals, associated items, etc) is in the span_bug! list.

@nrc

This comment has been minimized.

Member

nrc commented Sep 29, 2016

save-analysis stuff looks OK, module the one question

@bors

This comment has been minimized.

Contributor

bors commented Oct 4, 2016

☔️ The latest upstream changes (presumably #36953) made this pull request unmergeable. Please resolve the merge conflicts.

@petrochenkov petrochenkov force-pushed the petrochenkov:def branch from a6e3443 to d669a0e Oct 4, 2016

Remove some unused methods from metadata
Address comments + Fix rebase

@petrochenkov petrochenkov force-pushed the petrochenkov:def branch from d669a0e to bc0eabd Oct 4, 2016

@petrochenkov

This comment has been minimized.

Contributor

petrochenkov commented Oct 4, 2016

Rebased, updated.

@eddyb

This comment has been minimized.

Member

eddyb commented Oct 4, 2016

@bors r+

@bors

This comment has been minimized.

Contributor

bors commented Oct 4, 2016

📌 Commit bc0eabd has been approved by eddyb

@bors

This comment has been minimized.

Contributor

bors commented Oct 4, 2016

⌛️ Testing commit bc0eabd with merge fd065a8...

bors added a commit that referenced this pull request Oct 4, 2016

Auto merge of #36814 - petrochenkov:def, r=eddyb
Refactoring/bugfixing around definitions for struct/variant constructors

 d917c36 separates definitions for struct/variant constructors living in value namespace from struct/variant type definitions.

adfb378 fixes cross-crate resolution of reexports reexporting half-items, like struct constructors without struct type or types without constructor. Such reexports can appear due to glob shadowing.
Resolution now is not affected by the order in which items and reexports are decoded from metadata (cc #31337 (comment)). `try_define` is not used during building reduced graph anymore.
500 lines of this PR are tests for this exotic situation, the remaining line diff count is actually negative! :)

c695d0c (and partially aabf132) moves most of pattern resolution checks from typeck to resolve (except those checking for associated items), uses the same wording for pattern resolution error messages from both typeck and resolve and makes the messages more precise.

11e3524 fixes seemingly incorrectly set `NON_ZERO_SIZED` attributes for struct/variant ctors in const eval.

4586fea eliminates `ty::VariantKind` in favor of `def::CtorKind`. The logic is that variant kinds are irrelevant for types, they make sense only when we deal with constructor functions/constants. Despite that `VariantDefData` still keeps a copy of `CtorKind`, but it's used only for various kinds of pretty-printing (and for storing in metadata).

aabf132 is mostly a cleanup of various impossible or improperly used definitions, and other small definition cleanups.

cc @jseyfried
r? @eddyb

@bors bors merged commit bc0eabd into rust-lang:master Oct 5, 2016

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment