-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
incorrect error report: treat the Option field as iterator for take()
method call
#15027
Comments
Probably rust-lang/chalk#727 like #14949 and #14933. |
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... |
Yeah, you're right: I mistakenly picked this one instead of the "two iterator arguments" reports. |
…t-Analyzer, related to this issue: rust-lang/rust-analyzer#15027. Revert back when that issue is solved.
I would like to give an update. In recent RA versions (rust-analyzer version: 0.3.1975-standalone (71a816a 2024-05-26)), this error still exist, but in my case #14933, the error can go away if I:
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
The text was updated successfully, but these errors were encountered: