parse and handle `where T = U` predicate by JulianKnodt · Pull Request #87471 · rust-lang/rust

JulianKnodt · 2021-07-26T07:47:01Z

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

fee1-dead · 2021-07-26T11:57:25Z

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

varkor · 2021-07-27T10:26:03Z

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

JulianKnodt · 2021-07-27T17:29:50Z

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.

bors · 2021-07-28T09:17:58Z

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

varkor

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

varkor · 2021-07-28T17:52:14Z

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

r? @nikomatsakis

JulianKnodt · 2021-07-28T19:53:52Z

TODO create a new fulfillment error code

JulianKnodt · 2021-07-28T19:54:13Z

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

JulianKnodt · 2021-07-28T19:55:16Z

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

nikomatsakis · 2021-07-30T11:31:19Z

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 · 2021-07-30T14:57:09Z

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

JulianKnodt · 2021-07-30T17:48:37Z

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!

Syntactically reject equality predicates ### Background (History) Equality predicates have been *syntactically* valid since PR rust-lang#39158 / nightly-2017-02-02 / 1.16 (released 2017-03-16, 9 years ago), both forms that is: `$ty = $ty` *and* `$ty == $ty`. They're not registered as an unstable feature despite having a tracking issue (rust-lang#20041). Naturally, they don't have a feature gate. Of course, we reject them post-expansion, so they are still semantically invalid. Parser scaffolding for `$ident = $ty` was added in RUST-19391 (2014) which was then generalized to `$ty = $ty` in RUST-20002 (2014) and extended to additionally cover `$ty == $ty` in RUST-39158 (2017). As mentioned, the last PR also made them grammatical. RUST-87471 (2021) attempted to start impl'ing typeck'ing but it was closed due to concerns: rust-lang#87471 (comment) (already back in 2017 there were concerns: https://github.com/rust-lang/rust/pull/39158/changes#r97811244). In 2022, T-lang discussed this feature during a meeting and raised concerns: rust-lang#20041 (comment). However, they were inclined to accept a restricted form, namely `T::AssocTy = $ty` (`T` is a (self) ty param or a self ty alias) and `<$ty as Trait>::AssocTy = $ty` since that's trivial to support in HIR ty lowering (this is still accurate). ### Change This renders equality predicates `$ty = $ty` and `$ty == $ty` syntactically invalid again. On stable, they're merely semantically invalid. This is motivated by the fact that 1. their syntax isn't even decided upon 1. should it be `=` or `==`? 2. should the LHS be syntactically restricted to (possibly qualified) paths (i.e., *TypePath | QualifiedPathInType*), only semantically or not at all? * "syntactically" could indeed make sense since we might want to generalize types to so-called *terms* here (i.e., *Type | GenericArgsConst*) for [mGCA](rust-lang#132980) but we can't generalize `$ty = $ty` to `$term = $term` due to ambiguities [^1] that would require backtracking whereas `$typepath = $term` wouldn't have that problem 2. we might (decide to) never impl this feature * after all, implementation concerns were raised as early as 9 years ago which are still relevant today even with the next-gen trait solver on the horizon 3. the compiler + tools contain a bunch of code for dealing with these predicates * like lowering, name resolution, rustfmt and Clippy * that's entirely useless since they get unconditionally rejected anyway * this code doesn't need to exist (for now) I've merely upgraded the semantic hard error to a syntactic hard error, I've intentionally not introduced an unstable feature under which equality predicates become legal. That's because a hard error is easier to push through procedurally, it's an important first step (we can always turn it into a feature gate error later on) and since this potential feature isn't backed by any official lang experiment. I don't consider T-lang's message rust-lang#20041 (comment) from 2022 to be sufficient because it doesn't answer questions like (1.i), (1.ii) or whether code like `T: Trait<A>, <T as Trait<B>>::AssocTy = Ty` (`A` ≠ `B`) or `T: Trait<'r>, for<'a> <T as Trait<'a>>::AssocTy = Ty` should be legal (which would be more powerful / could lead to typechecking issues, idk) or not assuming we're going with the restricted form ofc (we would need input from T-types). ### Lang nomination rust-lang#153513 (comment) [^1]: Code lile `fn f() -> i32 where { 0 }` is intentionally legal today but if we had `$term = $term` the `{ 0 }` could then also be the start of an equality predicate like `{ 0 } = 0`.

Syntactically reject equality predicates ### Background (History) Equality predicates have been *syntactically* valid since PR rust-lang#39158 / nightly-2017-02-02 / 1.16 (released 2017-03-16, 9 years ago), both forms that is: `$ty = $ty` *and* `$ty == $ty`. They're not registered as an unstable feature despite having a tracking issue (rust-lang#20041). Naturally, they don't have a feature gate. Of course, we reject them post-expansion, so they are still semantically invalid. Parser scaffolding for `$ident = $ty` was added in RUST-19391 (2014) which was then generalized to `$ty = $ty` in RUST-20002 (2014) and extended to additionally cover `$ty == $ty` in RUST-39158 (2017). As mentioned, the last PR also made them grammatical. RUST-87471 (2021) attempted to start impl'ing typeck'ing but it was closed due to concerns: rust-lang#87471 (comment) (already back in 2017 there were concerns: https://github.com/rust-lang/rust/pull/39158/changes#r97811244). In 2022, T-lang discussed this feature during a meeting and raised concerns: rust-lang#20041 (comment). However, they were inclined to accept a restricted form, namely `T::AssocTy = $ty` (`T` is a (self) ty param or a self ty alias) and `<$ty as Trait>::AssocTy = $ty` since that's trivial to support in HIR ty lowering (this is still accurate). ### Change This renders equality predicates `$ty = $ty` and `$ty == $ty` syntactically invalid again. On stable, they're merely semantically invalid. This is motivated by the fact that 1. their syntax isn't even decided upon 1. should it be `=` or `==`? 2. should the LHS be syntactically restricted to (possibly qualified) paths (i.e., *TypePath | QualifiedPathInType*), only semantically or not at all? * "syntactically" could indeed make sense since we might want to generalize types to so-called *terms* here (i.e., *Type | GenericArgsConst*) for [mGCA](rust-lang#132980) but we can't generalize `$ty = $ty` to `$term = $term` due to ambiguities [^1] that would require backtracking whereas `$typepath = $term` wouldn't have that problem 2. we might (decide to) never impl this feature * after all, implementation concerns were raised as early as 9 years ago which are still relevant today even with the next-gen trait solver on the horizon 3. the compiler + tools contain a bunch of code for dealing with these predicates * like lowering, name resolution, rustfmt and Clippy * that's entirely useless since they get unconditionally rejected anyway * this code doesn't need to exist (for now) I've merely upgraded the semantic hard error to a syntactic hard error, I've intentionally not introduced an unstable feature under which equality predicates become legal. That's because a hard error is easier to push through procedurally, it's an important first step (we can always turn it into a feature gate error later on) and since this potential feature isn't backed by any official lang experiment. I don't consider T-lang's message rust-lang#20041 (comment) from 2022 to be sufficient because it doesn't answer questions like (1.i), (1.ii) or whether code like `T: Trait<A>, <T as Trait<B>>::AssocTy = Ty` (`A` ≠ `B`) or `T: Trait<'r>, for<'a> <T as Trait<'a>>::AssocTy = Ty` should be legal (which would be more powerful / could lead to typechecking issues, idk) or not assuming we're going with the restricted form ofc (we would need input from T-types). ### Lang nomination rust-lang#153513 (comment) [^1]: Code like `fn f() -> i32 where { 0 }` is intentionally legal today but if we had `$term = $term` the `{ 0 }` could then also be the start of an equality predicate like `{ 0 } = 0`.

Rollup merge of #153513 - fmease:gate-eq-pred, r=jackh726 Syntactically reject equality predicates ### Background (History) Equality predicates have been *syntactically* valid since PR #39158 / nightly-2017-02-02 / 1.16 (released 2017-03-16, 9 years ago), both forms that is: `$ty = $ty` *and* `$ty == $ty`. They're not registered as an unstable feature despite having a tracking issue (#20041). Naturally, they don't have a feature gate. Of course, we reject them post-expansion, so they are still semantically invalid. Parser scaffolding for `$ident = $ty` was added in RUST-19391 (2014) which was then generalized to `$ty = $ty` in RUST-20002 (2014) and extended to additionally cover `$ty == $ty` in RUST-39158 (2017). As mentioned, the last PR also made them grammatical. RUST-87471 (2021) attempted to start impl'ing typeck'ing but it was closed due to concerns: #87471 (comment) (already back in 2017 there were concerns: https://github.com/rust-lang/rust/pull/39158/changes#r97811244). In 2022, T-lang discussed this feature during a meeting and raised concerns: #20041 (comment). However, they were inclined to accept a restricted form, namely `T::AssocTy = $ty` (`T` is a (self) ty param or a self ty alias) and `<$ty as Trait>::AssocTy = $ty` since that's trivial to support in HIR ty lowering (this is still accurate). ### Change This renders equality predicates `$ty = $ty` and `$ty == $ty` syntactically invalid again. On stable, they're merely semantically invalid. This is motivated by the fact that 1. their syntax isn't even decided upon 1. should it be `=` or `==`? 2. should the LHS be syntactically restricted to (possibly qualified) paths (i.e., *TypePath | QualifiedPathInType*), only semantically or not at all? * "syntactically" could indeed make sense since we might want to generalize types to so-called *terms* here (i.e., *Type | GenericArgsConst*) for [mGCA](#132980) but we can't generalize `$ty = $ty` to `$term = $term` due to ambiguities [^1] that would require backtracking whereas `$typepath = $term` wouldn't have that problem 2. we might (decide to) never impl this feature * after all, implementation concerns were raised as early as 9 years ago which are still relevant today even with the next-gen trait solver on the horizon 3. the compiler + tools contain a bunch of code for dealing with these predicates * like lowering, name resolution, rustfmt and Clippy * that's entirely useless since they get unconditionally rejected anyway * this code doesn't need to exist (for now) I've merely upgraded the semantic hard error to a syntactic hard error, I've intentionally not introduced an unstable feature under which equality predicates become legal. That's because a hard error is easier to push through procedurally, it's an important first step (we can always turn it into a feature gate error later on) and since this potential feature isn't backed by any official lang experiment. I don't consider T-lang's message #20041 (comment) from 2022 to be sufficient because it doesn't answer questions like (1.i), (1.ii) or whether code like `T: Trait<A>, <T as Trait<B>>::AssocTy = Ty` (`A` ≠ `B`) or `T: Trait<'r>, for<'a> <T as Trait<'a>>::AssocTy = Ty` should be legal (which would be more powerful / could lead to typechecking issues, idk) or not assuming we're going with the restricted form ofc (we would need input from T-types). ### Lang nomination #153513 (comment) [^1]: Code like `fn f() -> i32 where { 0 }` is intentionally legal today but if we had `$term = $term` the `{ 0 }` could then also be the start of an equality predicate like `{ 0 } = 0`.

Syntactically reject equality predicates ### Background (History) Equality predicates have been *syntactically* valid since PR rust-lang/rust#39158 / nightly-2017-02-02 / 1.16 (released 2017-03-16, 9 years ago), both forms that is: `$ty = $ty` *and* `$ty == $ty`. They're not registered as an unstable feature despite having a tracking issue (rust-lang/rust#20041). Naturally, they don't have a feature gate. Of course, we reject them post-expansion, so they are still semantically invalid. Parser scaffolding for `$ident = $ty` was added in RUST-19391 (2014) which was then generalized to `$ty = $ty` in RUST-20002 (2014) and extended to additionally cover `$ty == $ty` in RUST-39158 (2017). As mentioned, the last PR also made them grammatical. RUST-87471 (2021) attempted to start impl'ing typeck'ing but it was closed due to concerns: rust-lang/rust#87471 (comment) (already back in 2017 there were concerns: https://github.com/rust-lang/rust/pull/39158/changes#r97811244). In 2022, T-lang discussed this feature during a meeting and raised concerns: rust-lang/rust#20041 (comment). However, they were inclined to accept a restricted form, namely `T::AssocTy = $ty` (`T` is a (self) ty param or a self ty alias) and `<$ty as Trait>::AssocTy = $ty` since that's trivial to support in HIR ty lowering (this is still accurate). ### Change This renders equality predicates `$ty = $ty` and `$ty == $ty` syntactically invalid again. On stable, they're merely semantically invalid. This is motivated by the fact that 1. their syntax isn't even decided upon 1. should it be `=` or `==`? 2. should the LHS be syntactically restricted to (possibly qualified) paths (i.e., *TypePath | QualifiedPathInType*), only semantically or not at all? * "syntactically" could indeed make sense since we might want to generalize types to so-called *terms* here (i.e., *Type | GenericArgsConst*) for [mGCA](rust-lang/rust#132980) but we can't generalize `$ty = $ty` to `$term = $term` due to ambiguities [^1] that would require backtracking whereas `$typepath = $term` wouldn't have that problem 2. we might (decide to) never impl this feature * after all, implementation concerns were raised as early as 9 years ago which are still relevant today even with the next-gen trait solver on the horizon 3. the compiler + tools contain a bunch of code for dealing with these predicates * like lowering, name resolution, rustfmt and Clippy * that's entirely useless since they get unconditionally rejected anyway * this code doesn't need to exist (for now) I've merely upgraded the semantic hard error to a syntactic hard error, I've intentionally not introduced an unstable feature under which equality predicates become legal. That's because a hard error is easier to push through procedurally, it's an important first step (we can always turn it into a feature gate error later on) and since this potential feature isn't backed by any official lang experiment. I don't consider T-lang's message rust-lang/rust#20041 (comment) from 2022 to be sufficient because it doesn't answer questions like (1.i), (1.ii) or whether code like `T: Trait<A>, <T as Trait<B>>::AssocTy = Ty` (`A` ≠ `B`) or `T: Trait<'r>, for<'a> <T as Trait<'a>>::AssocTy = Ty` should be legal (which would be more powerful / could lead to typechecking issues, idk) or not assuming we're going with the restricted form ofc (we would need input from T-types). ### Lang nomination rust-lang/rust#153513 (comment) [^1]: Code like `fn f() -> i32 where { 0 }` is intentionally legal today but if we had `$term = $term` the `{ 0 }` could then also be the start of an equality predicate like `{ 0 } = 0`.

rust-highfive assigned varkor Jul 26, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 26, 2021

JulianKnodt changed the title ~~add in where equality predicate~~ parse and handle where T = U predicate Jul 26, 2021

This comment has been minimized.

Sign in to view

JulianKnodt marked this pull request as draft July 26, 2021 08:34

JulianKnodt force-pushed the where_eq branch from cfdbecf to a332746 Compare July 26, 2021 08:52

This comment has been minimized.

Sign in to view

PatchMixolydic reviewed Jul 26, 2021

View reviewed changes

Comment thread compiler/rustc_feature/src/active.rs Outdated

JulianKnodt force-pushed the where_eq branch from a332746 to f51daf3 Compare July 26, 2021 17:21

This comment has been minimized.

Sign in to view

JulianKnodt force-pushed the where_eq branch from f51daf3 to d5f61a2 Compare July 27, 2021 07:51

JulianKnodt force-pushed the where_eq branch 2 times, most recently from 2ebff68 to 3b7341f Compare July 27, 2021 23:23

JulianKnodt marked this pull request as ready for review July 27, 2021 23:23

JulianKnodt force-pushed the where_eq branch 2 times, most recently from 49baae2 to a9a5025 Compare July 27, 2021 23:27

This comment has been minimized.

Sign in to view

JulianKnodt force-pushed the where_eq branch from a9a5025 to e6ea810 Compare July 27, 2021 23:42

JulianKnodt mentioned this pull request Jul 27, 2021

Tracking Issue for where T = U #87533

Closed

3 tasks

JulianKnodt force-pushed the where_eq branch from e6ea810 to 54283f5 Compare July 27, 2021 23:49

This comment has been minimized.

Sign in to view

JulianKnodt force-pushed the where_eq branch from 54283f5 to c5074dc Compare July 28, 2021 02:06

This comment has been minimized.

Sign in to view

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

JulianKnodt force-pushed the where_eq branch from a25ac5a to 1e0664f Compare July 28, 2021 17:00

varkor reviewed Jul 28, 2021

View reviewed changes

Comment thread compiler/rustc_feature/src/active.rs Outdated

Comment thread compiler/rustc_parse/src/parser/generics.rs Outdated

rust-highfive assigned nikomatsakis and unassigned varkor Jul 28, 2021

JulianKnodt force-pushed the where_eq branch 2 times, most recently from af0231b to 7695c47 Compare July 28, 2021 19:40

JulianKnodt commented Jul 28, 2021

View reviewed changes

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

This comment has been minimized.

Sign in to view

JulianKnodt force-pushed the where_eq branch from c2c011d to e9f6c71 Compare July 29, 2021 05:35

This comment has been minimized.

Sign in to view

JulianKnodt force-pushed the where_eq branch from e9f6c71 to 25193ed Compare July 29, 2021 05:53

This comment has been minimized.

Sign in to view

JulianKnodt force-pushed the where_eq branch from 25193ed to 2e5d212 Compare July 29, 2021 06:18

This comment has been minimized.

Sign in to view

add in where equality predicate

20a4669

JulianKnodt force-pushed the where_eq branch from 2e5d212 to 20a4669 Compare July 29, 2021 08:01

JulianKnodt closed this Jul 30, 2021

fmease mentioned this pull request Mar 6, 2026

Syntactically reject equality predicates #153513

Merged

Uh oh!

Conversation

JulianKnodt commented Jul 26, 2021 • edited by varkor Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

Uh oh!

fee1-dead commented Jul 26, 2021

Uh oh!

This comment has been minimized.

varkor commented Jul 27, 2021

Uh oh!

JulianKnodt commented Jul 27, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

bors commented Jul 28, 2021

Uh oh!

varkor left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

varkor commented Jul 28, 2021

Uh oh!

Uh oh!

JulianKnodt Jul 28, 2021

Choose a reason for hiding this comment

Uh oh!

JulianKnodt Jul 28, 2021

Choose a reason for hiding this comment

Uh oh!

Uh oh!

JulianKnodt Jul 28, 2021

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

nikomatsakis commented Jul 30, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bors commented Jul 30, 2021

Uh oh!

JulianKnodt commented Jul 30, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

JulianKnodt commented Jul 26, 2021 •

edited by varkor

Loading

JulianKnodt commented Jul 27, 2021 •

edited

Loading

nikomatsakis commented Jul 30, 2021 •

edited

Loading