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

parse and handle where T = U predicate #87471

Closed
wants to merge 1 commit into from

Conversation

JulianKnodt
Copy link
Contributor

@JulianKnodt JulianKnodt commented Jul 26, 2021

Updates #20041.

I took the most low-budget approach to adding equality checks (2 subtype checks in each direction), if it makes more sense to add in one check that does just equality, please let me know.

r? @varkor

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 26, 2021
@JulianKnodt JulianKnodt changed the title add in where equality predicate parse and handle where T = U predicate Jul 26, 2021
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@fee1-dead
Copy link
Member

I think making it an actual PredicateKind would be better. You can use rustc_infer::infer::equate to do this i think

@rust-log-analyzer

This comment has been minimized.

@varkor
Copy link
Member

varkor commented Jul 27, 2021

What's the status on the previous blockers? Have these been addressed now?

@JulianKnodt
Copy link
Contributor Author

JulianKnodt commented Jul 27, 2021

It's not so clear to me whether the previous blockers are completed, but given the time that passed since then, I wouldn't be surprised if they have. I still need to clean up some of the branches (since I just threw them all in last night), and will explore if this is feasible.

@JulianKnodt JulianKnodt force-pushed the where_eq branch 2 times, most recently from 2ebff68 to 3b7341f Compare July 27, 2021 23:23
@JulianKnodt JulianKnodt marked this pull request as ready for review July 27, 2021 23:23
@JulianKnodt JulianKnodt force-pushed the where_eq branch 2 times, most recently from 49baae2 to a9a5025 Compare July 27, 2021 23:27
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@JulianKnodt JulianKnodt force-pushed the where_eq branch 3 times, most recently from 5e385fb to a25ac5a Compare July 28, 2021 03:25
@bors
Copy link
Contributor

bors commented Jul 28, 2021

☔ The latest upstream changes (presumably #86735) made this pull request unmergeable. Please resolve the merge conflicts.

Copy link
Member

@varkor varkor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could do with more tests (both successful and error cases). Also, could you add tests for the cases @nikomatsakis mentions in #22074 (comment)?

compiler/rustc_feature/src/active.rs Outdated Show resolved Hide resolved
compiler/rustc_parse/src/parser/generics.rs Show resolved Hide resolved
@varkor
Copy link
Member

varkor commented Jul 28, 2021

Since @nikomatsakis reviewed the original PR (#22074) that was closed, I'm going to reassign to them.

r? @nikomatsakis

@rust-highfive rust-highfive assigned nikomatsakis and unassigned varkor Jul 28, 2021
@JulianKnodt JulianKnodt force-pushed the where_eq branch 2 times, most recently from af0231b to 7695c47 Compare July 28, 2021 19:40
compiler/rustc_trait_selection/src/traits/object_safety.rs Outdated Show resolved Hide resolved
match self.selcx.infcx().can_eq(obligation.param_env, lhs, rhs) {
Ok(()) => ProcessResult::Changed(vec![]),
Err(e) => ProcessResult::Error(FulfillmentErrorCode::CodeSubtypeError(
ExpectedFound::new(false, lhs, rhs),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO create a new fulfillment error code

span,
"type-equate requirement gave wrong error: `{:?}`",
obligation
)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not entirely sure what this was referencing, I suspect it's fine to leave this?

compiler/rustc_typeck/src/collect.rs Outdated Show resolved Hide resolved
@@ -327,6 +327,7 @@ impl<'a> Clean<Option<WherePredicate>> for ty::Predicate<'a> {
ty::PredicateKind::RegionOutlives(pred) => pred.clean(cx),
ty::PredicateKind::TypeOutlives(pred) => pred.clean(cx),
ty::PredicateKind::Projection(pred) => Some(pred.clean(cx)),
ty::PredicateKind::TypeEquate(..) => todo!(),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO not entirely sure whether to make this None, or have something else

@JulianKnodt JulianKnodt force-pushed the where_eq branch 2 times, most recently from 0900475 to c2c011d Compare July 29, 2021 05:21
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Jul 30, 2021

I don't think we really want this sort of where-clause. As I've come to learn more about the limits of various logics, introducing equality checks implies the ability to say things that we probably don't want to say (although I would like to support them someday, but only after we've made a transition to chalk and decided to do it). For example, being able to write fn foo<A, B>() where A = B would be really nifty, but we don't have the infrastructure to support that kind of equality properly, and it moves the logic from one class of logics to another (in particular we would no longer map so directly to 1st order hereditary harrop clauses -- as they don't permit equality in "assumptions", only in goals). I don't think that's a move we should make at this time.

@bors
Copy link
Contributor

bors commented Jul 30, 2021

☔ The latest upstream changes (presumably #87237) made this pull request unmergeable. Please resolve the merge conflicts.

@JulianKnodt
Copy link
Contributor Author

That's certainly fair, equality tends to imply != which seems to be quite controversial.
I was hoping to add this to improve specialization, so that you can provide impl<T: Iterator> Foo for T where T = Map/Other<...>, but given the additional burdens it's understandable.
In the future if/when this future is desired, this PR can be revived but I'll close it for now.

Please let me know if there is additional work elsewhere I can do to help move specialization along!

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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants