E0122: clarify wording #43176
E0122: clarify wording #43176
Conversation
|
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
src/librustc_typeck/diagnostics.rs
Outdated
| 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. |
There was a problem hiding this comment.
[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)
There was a problem hiding this comment.
oops did not know about this -- will fix.
| 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: |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
Could you elaborate? Are you saying there is a difference between the constraint being "not enforced" and "entirely ignored"?
There was a problem hiding this comment.
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 required T: Trait.
There was a problem hiding this comment.
the constraint is only ignored when referencing the alias, not within it.
Are you sure?
This is accepted:
struct Test<T: Copy> { t : T}
type MyTest<T> = Test<T>;And so it this:
trait Test {
type Type;
}
type MyTest<T> = <T as Test>::Type;To me it looks like constraints are not at all checked or enforced inside aliases.
There was a problem hiding this comment.
@nikomatsakis Do we not do any WF-checking in type aliases?
There was a problem hiding this comment.
@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.
aidanhs
added
the
S-waiting-on-author
|
What's the status on this PR, @RalfJung @eddyb? Are we waiting for an answer for this comment from @nikomatsakis? |
|
@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. |
|
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? |
|
ok, sounds like this should be waiting on review then, since @RalfJung is waiting on input from @nikomatsakis ! |
carols10cents
added
S-waiting-on-review
|
note: @nikomatsakis is on vacation and is behind on notifications. |
aidanhs
added
S-waiting-on-review
|
Ping @nikomatsakis - not sure what your current status is with wading through notifications, just want to keep this on your radar for review! |
|
note: @nikomatsakis is still on vacation and is behind on notifications. |
|
@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! |
|
Oh well. @bors r+ |
|
📌 Commit 5067ef2 has been approved by |
|
@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.
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.
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.