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.

Sign up for GitHub

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

Jump to bottom

Add experimental support for for<T> binders in limited positions #81

Closed
1 of 3 tasks
compiler-errors opened this issue Jan 27, 2023 · 6 comments
Closed
1 of 3 tasks

Add experimental support for for<T> binders in limited positions #81

compiler-errors opened this issue Jan 27, 2023 · 6 comments
Labels
final-comment-period The FCP has started, most (if not all) team members are in agreement major-change A major change proposal T-types Add this label so rfcbot knows to poll the types team to-announce Announce this issue on triage meeting

Comments

@compiler-errors
Copy link
Member

Proposal

Modify the resolver and type system to support for<T> in where clauses and associated item bounds (not object types or return-position impl traits).

Why?

  1. They should eventually also be useful for things like where clauses involving GATs (e.g. where for<T> Self::Assoc<T>: Trait).
  2. This will allow us to test out ty::Bound and ty::Placeholder a bit more, even if currently they're pretty useless on their own (i.e. without implication predicates).
  3. They should eventually work synergistically with implication predicates, if or when we add support for those (e.g. where for<T: Debug> Self::Assoc<T>: Debug).

Side-note: If anyone thinks this should be a compiler MCP, I'd be happy to move this over there. If this is better suited for a T-lang initiative, or needs a pre-RFC, then let me know.

Mentors or Reviewers

I've got a branch that mostly implements support for this, but it needs major cleaning up. I'm willing to do that work, but I just don't want to invest too much time to clean it up unless there's reasonable interest in support for type binders from other team members.
rust-lang/rust@master...compiler-errors:rust:non_lifetime_binders

Process

The main points of the Major Change Process are as follows:

  • File an issue describing the proposal.
  • A types team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
    • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
    • Types team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
  • Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
@compiler-errors compiler-errors added major-change A major change proposal T-types Add this label so rfcbot knows to poll the types team labels Jan 27, 2023
@rustbot
Copy link
Collaborator

rustbot commented Jan 27, 2023

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/types

@rustbot rustbot added the to-announce Announce this issue on triage meeting label Jan 27, 2023
@jackh726
Copy link
Member

@rustbot second

The actual PR for this will likely need lang okay, but from a types perspective, I think it's a good feature to experiment with.

@rustbot rustbot added the final-comment-period The FCP has started, most (if not all) team members are in agreement label Jan 27, 2023
@compiler-errors
Copy link
Member Author

Cool, noted

@compiler-errors compiler-errors mentioned this issue Jan 30, 2023
Merged
@zyansheep
Copy link

Would this addition resolve rust-lang/rfcs#1481 ?

@compiler-errors
Copy link
Member Author

@zyansheep, yes

@lcnr
Copy link
Contributor

lcnr commented Feb 14, 2023

closing as accepted

@lcnr lcnr closed this as completed Feb 14, 2023
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Feb 14, 2023
@matthiaskrgr
Rollup merge of rust-lang#107489 - compiler-errors:non_lifetime_binde…
71bad87 
…rs, r=cjgillot

Implement partial support for non-lifetime binders

This implements support for non-lifetime binders. It's pretty useless currently, but I wanted to put this up so the implementation can be discussed.

Specifically, this piggybacks off of the late-bound lifetime collection code in `rustc_hir_typeck::collect::lifetimes`. This seems like a necessary step given the fact we don't resolve late-bound regions until this point, and binders are sometimes merged.

Q: I'm not sure if I should go along this route, or try to modify the earlier nameres code to compute the right bound var indices for type and const binders eagerly... If so, I'll need to rename all these queries to something more appropriate (I've done this for `resolve_lifetime::Region` -> `resolve_lifetime::ResolvedArg`)

cc rust-lang/types-team#81

r? `@ghost`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Feb 16, 2023
@matthiaskrgr
Rollup merge of rust-lang#107489 - compiler-errors:non_lifetime_binde…
089e8c0 
…rs, r=cjgillot

Implement partial support for non-lifetime binders

This implements support for non-lifetime binders. It's pretty useless currently, but I wanted to put this up so the implementation can be discussed.

Specifically, this piggybacks off of the late-bound lifetime collection code in `rustc_hir_typeck::collect::lifetimes`. This seems like a necessary step given the fact we don't resolve late-bound regions until this point, and binders are sometimes merged.

Q: I'm not sure if I should go along this route, or try to modify the earlier nameres code to compute the right bound var indices for type and const binders eagerly... If so, I'll need to rename all these queries to something more appropriate (I've done this for `resolve_lifetime::Region` -> `resolve_lifetime::ResolvedArg`)

cc rust-lang/types-team#81

r? `@ghost`
@compiler-errors compiler-errors mentioned this issue Feb 17, 2023
Open
4 tasks
Jarcho pushed a commit to Jarcho/rust-clippy that referenced this issue Feb 25, 2023
@matthiaskrgr
Rollup merge of #107489 - compiler-errors:non_lifetime_binders, r=cjg…
cc60e21 
…illot

Implement partial support for non-lifetime binders

This implements support for non-lifetime binders. It's pretty useless currently, but I wanted to put this up so the implementation can be discussed.

Specifically, this piggybacks off of the late-bound lifetime collection code in `rustc_hir_typeck::collect::lifetimes`. This seems like a necessary step given the fact we don't resolve late-bound regions until this point, and binders are sometimes merged.

Q: I'm not sure if I should go along this route, or try to modify the earlier nameres code to compute the right bound var indices for type and const binders eagerly... If so, I'll need to rename all these queries to something more appropriate (I've done this for `resolve_lifetime::Region` -> `resolve_lifetime::ResolvedArg`)

cc rust-lang/types-team#81

r? `@ghost`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
final-comment-period The FCP has started, most (if not all) team members are in agreement major-change A major change proposal T-types Add this label so rfcbot knows to poll the types team to-announce Announce this issue on triage meeting
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@compiler-errors @zyansheep @lcnr @jackh726 @rustbot