Closed DeltaEpsilon7787 closed 2 months ago
Yikes, thanks for the report! Disappointed that this slipped through our CI.
@DeltaEpsilon7787 Macro expansion is weird. My guess is that the compiler distinguish the four different versions of "b".
It seems to be working just fine: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=435b75b4411195ae0a4fcce78aac4ca9
Do you have an example of something going wrong?
Looks like VSCode (and thus, rust LSP) are incorrectly determining the types of the vars in that situation.
Or rather, there is a disconnect in the LSP and the compiler.
To be fair, I can't blame it. What damn magic makes this work?
Thus, not a bug with itertools itself.
Copying your example in Sublime Text, I get the same (i32, f64, f64)
weirdness. rust-analyzer does not distinguish the b
s as good as the compiler does.
Yikes, thanks for the report! Disappointed that this slipped through our CI.
Just out of curiosity: Does anybody know if our CI would have cought this? (Would dig into this myself, but lack time.)
Well there is nothing to catch. But the detected weirdness appears when there are at least 3 arguments to izip
(the only interesting case since a.zip(b)
is good enough for 2 arguments).
We have tests with izip!(3 arguments)
so yeah, we should totally know if something breaks.
And one test for izip!(4 args)
apparently.
We figured out the reason for the weirdness, so to speak. It's due to hygienic macros. The macro expanded code cannot represent the fact that those different b have different context assigned to them, so they are not, in fact, 4 variables named b, they are 4 variables that are essentially named b+[ID1], b+[ID2], b+[ID3], b+[ID4] wherein ID is an anonymous identifier constructed on every macro expansion. Kind of like variable owner aspect, which is also invisible.
itertools = "0.13.0"
expands into
which is obviously wrong.