Uh oh!
There was an error while loading. Please reload this page.
Add const generics to infer (and transitive dependencies) - #59008
Conversation
eddyb
left a comment
There was a problem hiding this comment.
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.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
This is wrong because it is a projection, like TyProjection. cc @nikomatsakis
There was a problem hiding this comment.
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.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Is this enough? Don't we also need the type?
There was a problem hiding this comment.
Well, I think the type is carried in the ty::Const wrapper, for better or worse:
#[inline]pubfnmk_const_var(self,v:ConstVid<'tcx>,ty:Ty<'tcx>) -> &'tcxConst<'tcx>{self.mk_const(ty::Const{val:ConstValue::Infer(InferConst::Var(v)),
ty,})}There was a problem hiding this comment.
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.)
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Sounds like PlaceholderConst should contain the type.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I attempted propagating <'tcx> around when originally adding CanonicalVarKind::Const and found it to be impossible because CanonicalVarInfos are allocated in the global arena.
There was a problem hiding this comment.
Sound like we need to bother @nikomatsakis.
But also, aren't const types supposed to be always be "global"?
There was a problem hiding this comment.
AFAIK, types are only global after they have been lifted and their dependencies on type parameters and such are taken care of.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
commented
Mar 13, 2019
☔ The latest upstream changes (presumably #56864) made this pull request unmergeable. Please resolve the merge conflicts. |
e1d5810 to
94b7984Comparevarkor
commented
Mar 18, 2019
This is currently blocked on rust-lang/ena#19 and response from @nikomatsakis regarding the review comments above. |
This comment has been minimized.
This comment has been minimized.
crlf0710
commented
Mar 19, 2019
ena 0.12.0 is released. |
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
commented
Mar 24, 2019
☔ The latest upstream changes (presumably #58305) made this pull request unmergeable. Please resolve the merge conflicts. |
eddyb
commented
Mar 25, 2019
@varkor This should be unblocked now, just released |
varkor
commented
Mar 25, 2019
This is now blocked on #59415. |
eb2e115 to
a5d19dcComparevarkor
commented
Mar 27, 2019
I've addressed all the comments that aren't waiting on feedback from @nikomatsakis. |
Centril
commented
Mar 30, 2019
Reassigning the remainder of the review to r? @nikomatsakis then. |
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
commented
Apr 12, 2019
Does this still block on @nikomatsakis and @rust-lang/wg-traits? |
crlf0710
commented
Apr 12, 2019
@WiSaGaN Yes, althrough niko has responded that he'll add it to his list last week: |
Co-Authored-By: Gabriel Smith <yodaldevoid@users.noreply.github.com>
Co-Authored-By: Gabriel Smith <yodaldevoid@users.noreply.github.com>
Co-Authored-By: Gabriel Smith <yodaldevoid@users.noreply.github.com>
eddyb
commented
May 1, 2019
@bors r+ |
bors
commented
May 1, 2019
📌 Commit a68ed06 has been approved by |
bors
commented
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
commented
May 2, 2019
☀️ Test successful - checks-travis, status-appveyor |
… r=eddyb Refactor `TypeVariableOrigin` Removes some unused variants and extracts the common `Span` field. As suggested in rust-lang#59008 (comment). r? @eddyb
Refactor `TypeVariableOrigin` Removes some unused variants and extracts the common `Span` field. As suggested in #59008 (comment). r? @eddyb
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