Description
Given the following ---
type Result<T> = Result<T, anyhow::Error>;
The current output (with #88121, so on 1.56.0b4 and current nightly) is:
error[E0107]: this type alias takes 1 generic argument but 2 generic arguments were supplied
--> src/lib.rs:1:18
|
1 | type Result<T> = Result<T, anyhow::Error>;
| ^^^^^^ ------------- help: remove this generic argument
| |
| expected 1 generic argument
|
note: type alias defined here, with 1 generic parameter: `T`
--> src/lib.rs:1:6
|
1 | type Result<T> = Result<T, anyhow::Error>;
| ^^^^^^ -
error[E0391]: cycle detected when expanding type alias `Result`
--> src/lib.rs:1:18
|
1 | type Result<T> = Result<T, anyhow::Error>;
| ^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: ...which immediately requires expanding type alias `Result` again
= note: type aliases cannot be recursive
= help: consider using a struct, enum, or union instead to break the cycle
= help: see <https://doc.rust-lang.org/reference/types.html#recursive-types> for more information
note: cycle used when collecting item types in top-level module
--> src/lib.rs:1:1
|
1 | type Result<T> = Result<T, anyhow::Error>;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Some errors have detailed explanations: E0107, E0391.
For more information about an error, try `rustc --explain E0107`.
This seems less than ideal. Whilst E0391 makes it clearer that I'm holding it wrong, it doesn't quite address what's happened here clearly. (Also, E0107 was mildly confounding --- reporting it first here threw me for a bit.)
Perhaps, when reporting E0391 on a cycle where the RHS term was already in scope at the point of this declaration, adding a note that the LHS name is in scope on both sides would be helpful.
(More generally (a) I don't know how I feel about type aliases behaving more like letrec than let; (b) this feels more like a tiny tiny papercut than anything seriously problematic; and (c) thanks to @insou22 for reminding me that diagnostic quirks are bugs too.)