Open gftea opened 1 year ago
The reproduction in #16516 seems to be substantially smaller than other examples I've seen:
fn my_example(
_x: impl IntoIterator<Item = impl AsRef<str>>,
_y: impl IntoIterator<Item = impl AsRef<str>>,
) {
let mut cmd = std::process::Command::new("foo");
let mut child = cmd.spawn().unwrap();
child.stdin.take();
}
fn main() {}
Interestingly, removing a single parameter doesn't doesn't result in this lint firing.
@davidbarsky That's the same as #10653 which I'm not so sure is the same as this issue, since there are no trait bounds on type parameters in the original example here.
In general ".take() gets inferred as Iterator::take instead of Option::take" often is just a symptom of the type of the receiver being unknown, which can have any number of root causes. Although we should at least probably not show further arg-count-mismatch diagnostics if the method receiver was unknown...
@davidbarsky That's the same as #10653 which I'm not so sure is the same as this issue, since there are no trait bounds on type parameters in the original example here.
In general ".take() gets inferred as Iterator::take instead of Option::take" often is just a symptom of the type of the receiver being unknown, which can have any number of root causes. Although we should at least probably not show further arg-count-mismatch diagnostics if the method receiver was unknown...
Yeah, you're right: I mistakenly picked this one instead of the "two iterator arguments" reports.
I would like to give an update. In recent RA versions (rust-analyzer version: 0.3.1975-standalone (71a816a90 2024-05-26)), this error still exist, but in my case https://github.com/rust-lang/rust-analyzer/issues/14933, the error can go away if I:
cargo clean
I can't explain how this works but it is definitely reproducible. Makes the error less of a nuisance.
Also, it seems a same mechanism is also causing false error report in pattern matching (it will falsely report some match expressions to be non-exhaustive if there are nested pattern bindings). They both go away after the above "restart RA server" trick.
rust-analyzer version: (eg. output of "rust-analyzer: Show RA Version" command, accessible in VSCode via Ctrl/⌘+Shift+P)
rust-analyzer
version: 0.4.1547-standalone`rustc version: (eg. output of
rustc -V
)rustc 1.70.0 (90c541806 2023-05-31)
relevant settings: (eg. client settings, or environment variables like
CARGO
,RUSTC
,RUSTUP_HOME
orCARGO_HOME
)I had below config in vscode, but I think it is not relevant, because the fault is not from clippy
"rust-analyzer.check.command": "clippy",
Status analysis output
language server output
error report
See below screenshot, the
this.pending_event
is anOption<( ... )>
, but rust-analyzer interpret it as iterator, and report errorexpected 1 argument, found 0