Closed lemolatoon closed 1 week ago
At first glance, it sounds like a compiler bug that lazily resolves associated types of types containing generics.
@taiki-e Thank you for your quick response!
I tried checking expanded one.
impl<'a, T> ::core::iter::Iterator for Enum<'a, T>
where
A<T>: ::core::iter::Iterator,
{
type Item = <A<T> as ::core::iter::Iterator>::Item;
#[inline]
fn next(&mut self) -> ::core::option::Option<Self::Item> {
match self {
Enum::A(x) => <A<T> as ::core::iter::Iterator>::next(x),
Enum::B(x) => <B<'a> as ::core::iter::Iterator>::next(x),
}
}
// Other methods follows
}
This normal code emits a little easy to see error messages.
error[E0308]: `match` arms have incompatible types
--> src\expanded.rs:33:27
|
31 | / match self {
32 | | Enum::A(x) => <A<T> as ::core::iter::Iterator>::next(x),
| | ----------------------------------------- this is found to be of type `Option<<expanded::A<T> as Iterator>::Item>`
33 | | Enum::B(x) => <B<'a> as ::core::iter::Iterator>::next(x),
| | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `Option<<A<T> as Iterator>::Item>`, found `Option<usize>`
34 | | }
| |_________- `match` arms have incompatible types
|
= note: expected enum `Option<<expanded::A<T> as Iterator>::Item>`
found enum `Option<usize>`
= help: consider constraining the associated type `<expanded::A<T> as Iterator>::Item` to `usize` or calling a method that returns `<expanded::A<T> as Iterator>::Item`
= note: for more information, visit https://doc.rust-lang.org/book/ch19-03-advanced-traits.html
Now I am confident that this is not the bug of the derive macro, but compiler's bug or limitation.
Do you think is this compiler's bug? I will also check rustc's issues about this.
The way I produced the expanded one (iter_enum::lib.rs, derive_iterator) ↓
let tokens: TokenStream = quick_derive! { ... };
println!("{}", tokens.clone().to_string());
tokens
Closing as a compiler bug.
versions and environments
light description
I failed to compile enum deriving Iterator, where one field has lifetime parameter, and the other has type generics. Depending on the order of fields, compile can be succeed.
detailed description
I found the weird bug. Let's say I write the code below.
This can be compiled, but If I switch the enum field, this suddenly won't be compiled.
Actual Compile Error ↓