Issue warnings for late-bound regions in assoc type bindings and output types#32488
Closed
nikomatsakis wants to merge 9 commits intorust-lang:masterfrom
Closed
Issue warnings for late-bound regions in assoc type bindings and output types#32488nikomatsakis wants to merge 9 commits intorust-lang:masterfrom
nikomatsakis wants to merge 9 commits intorust-lang:masterfrom
Conversation
nikomatsakis
force-pushed
the
issue-32330-lbr-in-return-type-warning
branch
from
69d9954 to
4c4e3fe
Compare
Collaborator
|
☔ The latest upstream changes (presumably #32496) made this pull request unmergeable. Please resolve the merge conflicts. |
Contributor
There was a problem hiding this comment.
Name needs to be updated here.
Contributor
|
OK, this looks good to me. Tiny nits, r=me after rebase. |
This is a step towards fixing rust-lang#32330. The full fix would be a breaking change, so we begin by issuing warnings for scenarios that will break.
We ought not to be affecting inference state when assembling candidates, so invoke select inside of a probe.
Before we would ignore a candidate if it happened to be an impl with a default type. This change makes us never add the impl in the first place. This seems largely equivalent, though there might be some subtle difference in that -- before -- we would have failed to normalize if there was a "trait-def-candidate" contending with an (opaque) impl candidate. This corresponds I guess to a case like `<<A as Trait>::B as Trait2>::C`, and the definition of `Trait` contains a clause. Pretty obscure, but it seems like it's... ok to favor the trait definition in such a case.
nikomatsakis
force-pushed
the
issue-32330-lbr-in-return-type-warning
branch
from
4c4e3fe to
c534a14
Compare
Contributor
Author
|
@bors r=aturon |
Collaborator
|
📌 Commit c534a14 has been approved by |
Contributor
Author
|
Decided to revise this approach. Closing PR for now. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is part 1 of a series of patches to produce "future compatiblity" warnings for #32330. I have the actual fix in a branch, but I am planning to first land some patches so that we issue warnings for all the cases that will break once the fix is in place.
This particular PR issues a warning for fn types where a higher-ranked region appears only in the return type, such as
for<'a> fn() -> &'a i32, as well as for where clauses where a HR region appears only in a binding, such asfor<'a> Fn() -> &'a i32orfor<'a> Iterator<Item=&'a i32>.I also included some a general refactoring of projection that makes the "assembling candidate" phase side-effect free, as intended. This is useful for the work that @soltanmm and I have been doing on plumbing obligations around but is otherwise kind of orthogonal.
r? @aturon
cc @arielb1