E0122: clarify wording by RalfJung · Pull Request #43176 · rust-lang/rust

RalfJung · 2017-07-12T00:44:03Z

I assume the reason these constraints are not hard errors is backwards compatibility. If yes, I think the error explanation (at least the long form) should be clearer about that, which is what this PR does.

If not, the explanation should give some other suitable explanation.

rust-highfive · 2017-07-12T00:44:07Z

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

kennytm · 2017-07-12T03:58:44Z

-An attempt was made to add a generic constraint to a type alias. While Rust will
-allow this with a warning, it will not currently enforce the constraint.
+An attempt was made to add a generic constraint to a type alias. This constraint is
+entirely ignored. For backwards compatibility, Rust still allows this with a warning.


[00:12:30] error: description for error code E0122 contains a line longer than 80 characters. [00:12:30] if you're inserting a long URL use the footnote style to bypass this check. [00:12:30] --> /checkout/src/librustc_typeck/diagnostics.rs:13:1 [00:12:30] | [00:12:30] 13 | / register_long_diagnostics! { [00:12:30] 14 | | [00:12:30] 15 | | E0023: r##" [00:12:30] 16 | | A pattern used to match against an enum variant must provide a sub-pattern for [00:12:30] ... | [00:12:30] 4680 | | [00:12:30] 4681 | | } [00:12:30] | |_^ [00:12:30] | [00:12:30] = note: this error originates in a macro outside of the current crate [00:12:30] [00:12:30] error: aborting due to previous error(s)

oops did not know about this -- will fix.

eddyb · 2017-07-12T08:11:22Z

-Consider the example below:
+An attempt was made to add a generic constraint to a type alias. This constraint
+is entirely ignored. For backwards compatibility, Rust still allows this with a
+warning. Consider the example below:


This is incorrect. The constraint is required to use associated type syntax (without writing <T as Trait>::Assoc - which you can't for Fn traits on stable).

Could you elaborate? Are you saying there is a difference between the constraint being "not enforced" and "entirely ignored"?

Yes, the constraint is only ignored when referencing the alias, not within it. Actually I think <T as Trait>::Assoc still requires a T: Trait bound. And the only reason that works is we effectively recover a T: Trait bound from the presence of a <T as Trait>::Assoc type, even if we don't know whether the type came from somewhere which already requiredT: Trait.

the constraint is only ignored when referencing the alias, not within it.
Are you sure?
This is accepted:
structTest<T:Copy>{t:T}typeMyTest<T> = Test<T>;
And so it this:
traitTest{typeType;}typeMyTest<T> = <TasTest>::Type;
To me it looks like constraints are not at all checked or enforced inside aliases.

@nikomatsakis Do we not do any WF-checking in type aliases?

@eddyb at present, I think we do not! I expect we are going to make various changes here -- possibly in a "new epoch", but hopefully we can pull it off without that.

carols10cents · 2017-07-17T12:27:34Z

What's the status on this PR, @RalfJung @eddyb? Are we waiting for an answer for this comment from @nikomatsakis?

nikomatsakis · 2017-07-17T14:05:43Z

@eddyb @RalfJung -- funny, I've been meaning to bring this issue up as a back-compat concern. I'm hoping to make type aliases more "first class" -- i.e., roll them into lazy normalization, which I think I see a way towards implementing now -- and of course we're going to have to wrestle with the question of what to do about existing broken cases.

RalfJung · 2017-07-19T20:39:09Z

The label "waiting on author" seems to be wrong... that would be waiting on me, and then I'm not sure what I am expected to do.^^

@nikomatsakis is the new wording of the message ("this constraint is entirely ignored") correct or not?

carols10cents · 2017-07-24T14:18:22Z

ok, sounds like this should be waiting on review then, since @RalfJung is waiting on input from @nikomatsakis !

arielb1 · 2017-07-25T23:21:20Z

note: @nikomatsakis is on vacation and is behind on notifications.

aidanhs · 2017-08-03T19:08:47Z

Ping @nikomatsakis - not sure what your current status is with wading through notifications, just want to keep this on your radar for review!

arielb1 · 2017-08-06T15:34:19Z

note: @nikomatsakis is still on vacation and is behind on notifications.

alexcrichton · 2017-08-10T19:02:27Z

@eddyb you're the listed reviewer for this, but should that be moved over to @nikomatsakis? It looks like all the last comments are indicating that's the blocker!

eddyb · 2017-08-10T19:18:50Z

Oh well. @bors r+

bors · 2017-08-10T19:18:51Z

📌 Commit 5067ef2 has been approved by eddyb

aidanhs · 2017-08-10T19:40:04Z

@bors rollup

E0122: clarify wording I *assume* the reason these constraints are not hard errors is backwards compatibility. If yes, I think the error explanation (at least the long form) should be clearer about that, which is what this PR does. If not, the explanation should give some other suitable explanation.

Rollup of 18 pull requests - Successful merges: #43176, #43632, #43650, #43712, #43715, #43721, #43739, #43741, #43744, #43747, #43752, #43760, #43773, #43779, #43783, #43791, #43793, #43795 - Failed merges:

E0122: clarify wording I *assume* the reason these constraints are not hard errors is backwards compatibility. If yes, I think the error explanation (at least the long form) should be clearer about that, which is what this PR does. If not, the explanation should give some other suitable explanation.

rust-highfive assigned eddyb Jul 12, 2017

E0122: clarify wording
ba53f95

RalfJung force-pushed the explain branch from b89164f to ba53f95Compare July 12, 2017 00:44

kennytm reviewed Jul 12, 2017
View reviewed changes

fix line lengths
5067ef2

eddyb reviewed Jul 12, 2017
View reviewed changes

aidanhs added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jul 13, 2017

carols10cents added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 24, 2017

aidanhs added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 3, 2017

GuillaumeGomez mentioned this pull request Aug 11, 2017
Rollup of 18 pull requests #43800
Merged

MaloJaffre mentioned this pull request Aug 11, 2017
Rollup of 19 pull requests #43802
Closed

bors merged commit 5067ef2 into rust-lang:masterAug 11, 2017

RalfJung deleted the explain branch February 18, 2018 18:41

Uh oh!

Uh oh!

Conversation

RalfJung commented Jul 12, 2017

Uh oh!

rust-highfive commented Jul 12, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

carols10cents commented Jul 17, 2017

Uh oh!

nikomatsakis commented Jul 17, 2017

Uh oh!

RalfJung commented Jul 19, 2017

Uh oh!

carols10cents commented Jul 24, 2017

Uh oh!

arielb1 commented Jul 25, 2017

Uh oh!

aidanhs commented Aug 3, 2017

Uh oh!

arielb1 commented Aug 6, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexcrichton commented Aug 10, 2017

Uh oh!

eddyb commented Aug 10, 2017

Uh oh!

bors commented Aug 10, 2017

Uh oh!

aidanhs commented Aug 10, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

arielb1 commented Aug 6, 2017•
edited
Loading