Skip to content
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

Add const generics to infer (and transitive dependencies) #59008

Merged
merged 47 commits into from
May 2, 2019

Conversation

varkor
Copy link
Member

@varkor varkor commented Mar 8, 2019

Split out from #53645. This work is a collaborative effort with @yodaldevoid.

There are a number of stubs. These are mainly to ensure we don't overlook them when completing the implementation, but are not necessary for the initial implementation. We plan to address these in follow up PRs.

r? @eddyb / @nikomatsakis

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 8, 2019
Copy link
Member

@eddyb eddyb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, modulo comments, some of which require someone who understands certain typesystem interactions - I've pinged @nikomatsakis but I suspect @rust-lang/wg-traits can also help here.

src/librustc/infer/canonical/mod.rs Show resolved Hide resolved
src/librustc/infer/canonical/mod.rs Outdated Show resolved Hide resolved
src/librustc/infer/combine.rs Outdated Show resolved Hide resolved
src/librustc/infer/const_variable.rs Outdated Show resolved Hide resolved
src/librustc/infer/mod.rs Outdated Show resolved Hide resolved
src/librustc/ty/error.rs Outdated Show resolved Hide resolved
}
}
}
// FIXME(const_generics): this is probably wrong (regarding TyProjection)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is wrong because it is a projection, like TyProjection. cc @nikomatsakis

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, to be quite honest, I'm a bit confused by what the "normalization policy" is here. If this were doing eager normalization, as I would expect at the moment, then this doesn't seem wrong. But if it's lazy normalization, then indeed it is wrong. It seems like we can land it as is, but I think that overall it would be good to try and document and talk out the design of constants and const generics.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Design meeting! :)

#[derive(Copy, Clone, Debug)]
pub enum ConstVariableValue<'tcx> {
Known { value: &'tcx ty::LazyConst<'tcx> },
Unknown { universe: ty::UniverseIndex },
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this enough? Don't we also need the type?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I think the type is carried in the ty::Const wrapper, for better or worse:

    #[inline]
    pub fn mk_const_var(self, v: ConstVid<'tcx>, ty: Ty<'tcx>) -> &'tcx Const<'tcx> {
        self.mk_const(ty::Const {
            val: ConstValue::Infer(InferConst::Var(v)),
            ty,
        })
    }

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not carried around in Unknown, which I think is the part @eddyb was referring to. (There's some other discussion about this elsewhere, but there's a FIXME in the code about this now.)

self.tcx.mk_lazy_const(ty::LazyConst::Evaluated(
ty::Const {
val: ConstValue::Placeholder(placeholder_mapped),
ty: self.tcx.types.err, // FIXME(const_generics)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like PlaceholderConst should contain the type.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it probably should. The reason I didn't do it earlier was it ended up propagating <'tcx> everywhere and I wanted to make sure it was definitely necessary before going down that route.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I attempted propagating <'tcx> around when originally adding CanonicalVarKind::Const and found it to be impossible because CanonicalVarInfos are allocated in the global arena.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sound like we need to bother @nikomatsakis.

But also, aren't const types supposed to be always be "global"?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK, types are only global after they have been lifted and their dependencies on type parameters and such are taken care of.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Type parameters are "global" in this sense, only inference variables aren't.
I'm saying that I don't think we should ever have a constant value in the type system with an uninferred type.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. Something feels wrong here indeed. I'm trying too put my finger on what it is. I guess in short I don't like the idea of there being a type in the canonical-var-info -- I feel like types should in the canonicalized value.

I think what I would expect is that the placeholder doesn't replace the entire ty::Const, but rather just the ConstValue. In this way, it can be instantiated without needing the type.

(Similarly, in the existential case that appears above, you wouldn't make a "Fresh type variable" to represent its type -- that also seems wrong.)

@bors
Copy link
Contributor

bors commented Mar 13, 2019

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

@varkor
Copy link
Member Author

varkor commented Mar 18, 2019

This is currently blocked on rust-lang/ena#19 and response from @nikomatsakis regarding the review comments above.

@rust-highfive

This comment has been minimized.

@crlf0710
Copy link
Member

ena 0.12.0 is released.

@varkor
Copy link
Member Author

varkor commented Mar 20, 2019

I missed a detail in the previous pull request to ena: this is now blocked on rust-lang/ena#21.

@bors
Copy link
Contributor

bors commented Mar 24, 2019

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

@eddyb
Copy link
Member

eddyb commented Mar 25, 2019

@varkor This should be unblocked now, just released ena v0.13.

@varkor
Copy link
Member Author

varkor commented Mar 25, 2019

This is now blocked on #59415.

@varkor
Copy link
Member Author

varkor commented Mar 27, 2019

I've addressed all the comments that aren't waiting on feedback from @nikomatsakis.

@Centril
Copy link
Contributor

Centril commented Mar 30, 2019

Reassigning the remainder of the review to r? @nikomatsakis then.

@rust-highfive rust-highfive assigned nikomatsakis and unassigned eddyb Mar 30, 2019
@eddyb
Copy link
Member

eddyb commented Mar 30, 2019

Anyone else from @rust-lang/wg-traits want to take a look at the questions I left for @nikomatsakis, too?

@WiSaGaN
Copy link
Contributor

WiSaGaN commented Apr 12, 2019

Does this still block on @nikomatsakis and @rust-lang/wg-traits?

@crlf0710
Copy link
Member

@WiSaGaN Yes, althrough niko has responded that he'll add it to his list last week:
https://rust-lang.zulipchat.com/#narrow/stream/144729-wg-traits/topic/.2359008.20changes.20to.20infer

@eddyb
Copy link
Member

eddyb commented May 1, 2019

@bors r+

@bors
Copy link
Contributor

bors commented May 1, 2019

📌 Commit a68ed06 has been approved by eddyb

@bors 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 May 1, 2019
@bors
Copy link
Contributor

bors commented May 2, 2019

⌛ Testing commit a68ed06 with merge 92b5e20...

bors added a commit that referenced this pull request May 2, 2019
Add const generics to infer (and transitive dependencies)

Split out from #53645. This work is a collaborative effort with @yodaldevoid.

There are a number of stubs. These are mainly to ensure we don't overlook them when completing the implementation, but are not necessary for the initial implementation. We plan to address these in follow up PRs.

r? @eddyb / @nikomatsakis
@bors
Copy link
Contributor

bors commented May 2, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: eddyb
Pushing 92b5e20 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 2, 2019
@bors bors merged commit a68ed06 into rust-lang:master May 2, 2019
@varkor varkor deleted the const-generics-infer branch May 2, 2019 08:28
Centril added a commit to Centril/rust that referenced this pull request Jun 5, 2019
… r=eddyb

Refactor `TypeVariableOrigin`

Removes some unused variants and extracts the common `Span` field.

As suggested in rust-lang#59008 (comment).

r? @eddyb
bors added a commit that referenced this pull request Jun 6, 2019
Refactor `TypeVariableOrigin`

Removes some unused variants and extracts the common `Span` field.

As suggested in #59008 (comment).

r? @eddyb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants