Uh oh!
There was an error while loading. Please reload this page.
Implement RFC 2056 trivial constraints in where clauses - #48557
Conversation
rust-highfive
commented
Feb 26, 2018
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
bors
commented
Feb 27, 2018
☔ The latest upstream changes (presumably #48449) made this pull request unmergeable. Please resolve the merge conflicts. |
cramertj
commented
Feb 27, 2018
This is so cool! :) |
shepmaster
commented
Mar 4, 2018
Typo. You may want to double check any other places for the same one. |
nikomatsakis
left a comment
There was a problem hiding this comment.
D'oh! I had this review with a few initial questions for some time but never submitted it! Sorry about that. I've been wondering why you didn't respond ;)
There was a problem hiding this comment.
Can you clarify why you added this param_env.is_global() check?
There was a problem hiding this comment.
Hmm, looks like I added this before I put in the changes to ParamEnv::and from #48411. It doesn't appear to be needed now.
There was a problem hiding this comment.
Also, can you clarify how you avoid the soundness problems discussed here =)
Is that related to the global check?
There was a problem hiding this comment.
I couldn't create any soundness problems after removing this, so I can't really be sure that I have avoided it. See the tests for an idea of what I attempted.
It looks like the current caching is (at the time of making this PR) very conservative, which probably explains this though.
rust/src/librustc/traits/select.rs
Lines 1271 to 1282 in 3edb3cc
There was a problem hiding this comment.
Well, I guess this is part of how we avoid the soundness problems too. I am trying to decide if this is_global check on the param environment suffices. I think it probably does given the current definitions of elaboration, but won't once we have a better definition of implied bounds (but that will require the newer solver, in which this PR is sort of easier to implement anyway).
I am imagining cases like this:
traitFoowhereu32:Bar{}traitBar{}Now, if we were to fully elaborate, T: Foo would imply u32: Bar.
There was a problem hiding this comment.
Well, I guess this is part of how we avoid the soundness problems too.
Yes, but this only seemed to cause bounds to not apply in my testing.
I am imagining cases like this:
traitFoowhereu32:Bar{}traitBar{}Now, if we were to fully elaborate, T: Foo would imply u32: Bar.
True, but this is surely just as much a problem with fully elaborating
traitFoowhereVec<T>:Copy{}traitBar{}
There was a problem hiding this comment.
This is interesting. Should we remove Never from the enum? (Did you do so? If so, I missed it.)
There was a problem hiding this comment.
I just landed a change much like this.
There was a problem hiding this comment.
That's where it's from. 😄
nikomatsakis
commented
Mar 15, 2018
@matthewjasper so -- much as this PR somehow makes me mildly nervous -- I can't think of a reason this won't work =) I suggest you rebase and remove the WIP comment from the header, so I can r+ ... |
c03bacd to
b080ee2Comparematthewjasper
commented
Mar 15, 2018
rebased A few further changes:
@nikomatsakis Done, but this still needs a feature gate, right? |
nikomatsakis
commented
Mar 16, 2018
Um, yes, right. I was.. uh.. just testing you to see if you'd remember. |
nikomatsakis
commented
Mar 20, 2018
@matthewjasper let me know when you add feature gate then =) |
760cec8 to
fcfbfe0Comparematthewjasper
commented
Mar 21, 2018
@nikomatsakis Feature gate now added. I haven't feature-gated built-in trait bound errors (e.g. The commits are now a bit of a mess, but I can clean them up later. |
bors
commented
Mar 22, 2018
☔ The latest upstream changes (presumably #49264) made this pull request unmergeable. Please resolve the merge conflicts. |
nikomatsakis
commented
Mar 23, 2018
@matthewjasper thanks -- sorry for being slow, will re-review |
8ce2022 to
1c3854aCompare40eb071 to
ad37f44Comparead37f44 to
be2900cComparematthewjasper
commented
May 15, 2018
rebased. |
cramertj
commented
May 15, 2018
@bors r=nikomatsakis |
bors
commented
May 15, 2018
📌 Commit be2900c has been approved by |
bors
commented
May 16, 2018
Implement RFC 2056 trivial constraints in where clauses This is an implementation of the new behaviour for #48214. Tests are mostly updated to show the effects of this. Feature gate hasn't been added yet. Some things that are worth noting and are maybe not want we want * `&mut T: Copy` doesn't allow as much as someone might expect because there is often an implicit reborrow. * ~There isn't a check that a where clause is well-formed any more, so `where Vec<str>: Debug` is now allowed (without a `str: Sized` bound).~ r? @nikomatsakis
bors
commented
May 16, 2018
☀️ Test successful - status-appveyor, status-travis |
Prevent main from having a where clause. Closes#50714 Should this have a crater run? cc #48557, #48214 r? @nikomatsakis
This is an implementation of the new behaviour for #48214. Tests are mostly updated to show the effects of this. Feature gate hasn't been added yet.
Some things that are worth noting and are maybe not want we want
&mut T: Copydoesn't allow as much as someone might expect because there is often an implicit reborrow.There isn't a check that a where clause is well-formed any more, sowhere Vec<str>: Debugis now allowed (without astr: Sizedbound).r? @nikomatsakis