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

[draft] Revised approach to backport of PR #96970 #97036

Closed

Conversation

pnkfelix
Copy link
Member

Revised approach to backport of PR #96970

See discussion on zulip

pnkfelix added 2 commits May 14, 2022 01:58
This carries on with some of the ideas from PR 96970, but generalizes them
slightly to try to narrow the cases where the error fires. (It also sidesteps
the whole question of trying to deal with lifetime resolution during ast
lowering by just looking at names.)

More specifically: This tracks the depth of Return Position Opaque Ty (aka
Return Position Impl Trait aka RPIT). As it descends the AST, each time it does
lower_poly_trait_ref, it tracks what lifetimes are introduced there, and what
depth they were introduced at.

(As I write this, I realize that I probably didn't handle shadowed lifetimes
quite right; see below.)

Anyway, when it hits a use of a lifetime, it checks the depth. If the depths
don't match and we're in a nested RPIT, then it errors. (Compare this to PR
96970, which just errors unconditionally in the nested RPIT, without checking if
the depths match and thus it's a `for<'a>` that was introduced at the current
level as well, and thus should not be a problem.)

Regarding shadowing mistake: my code probably generates an error in a situation
like `impl for<'a> Trait1<Assoc=impl for<'a> Trait2<'a>>`, or something along
those lines. But that should be easy to fix.)

A follow-up commit will include the blessed test output, so you can see the
effect of this and compare it against PR 96970.

(I did not put in any new unit tests, but obviously we should make those too.)
… them against PR 96970 and it seems consistent but I have not inspected them carefully.
@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label May 14, 2022
@rust-highfive
Copy link
Collaborator

r? @cjgillot

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive
Copy link
Collaborator

⚠️ Warning ⚠️

  • Pull requests are usually filed against the master branch for this repo, but this one is against beta. Please double check that you specified the right target!

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 14, 2022
@pnkfelix
Copy link
Member Author

Let me mark this as a draft. At the very least, it should add a test of #96194 itself, as well as a test of the variant that @compiler-errors developed (playground) after I started musing about mixing the ordering a bit.

@pnkfelix pnkfelix changed the title Revised approach to backport of PR #96970 [draft] Revised approach to backport of PR #9697 May 14, 2022
@pnkfelix pnkfelix marked this pull request as draft May 14, 2022 06:12
@oli-obk oli-obk self-assigned this May 14, 2022
@mati865

This comment was marked as resolved.

@oli-obk oli-obk changed the title [draft] Revised approach to backport of PR #9697 [draft] Revised approach to backport of PR #96970 May 14, 2022
@cjgillot
Copy link
Contributor

#97039 and #97040 implement a simpler version of this check.

@oli-obk oli-obk closed this May 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants