ice unexpected sort of node in fn_sig(): Item(Item..`
#11065
Assignees
Comments
matthiaskrgr
added
C-bug
|
Smaller repro without the macros: use std::option::IntoIter;
fn main() {
const C: fn(IntoIter<i32>) -> IntoIter<i32> = <IntoIter<i32> as IntoIterator>::into_iter;
C(Some(5).into_iter()); // ICE here
}Seems like the @rustbot claim |
|
oh, hidden behind this ICE is also an FP. It basically boils down to having a macro that expands an use std::option::IntoIter;
fn takes_into_iter(_: impl IntoIterator<Item = i32>) {}
macro_rules! x {
($e:expr) => {
takes_into_iter($e); // lint here because `.into_iter()` is "redundant"
let _: IntoIter<i32> = $e; // removing `.into_iter()` leads to a type error here
};
}
fn main() {
x!(Some(5).into_iter());
}I guess we shouldn't lint if the expression is not just from a macro expansion, but also part (i.e. an argument) of a macro call |
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Aug 17, 2023
[`useless_conversion`]: only lint on paths to fn items and fix FP in macro Fixes rust-lang#11065 (which is actually two issues: an ICE and a false positive) It now makes sure that the function call path points to a function-like item (and not e.g. a `const` like in the linked issue), so that calling `TyCtxt::fn_sig` later in the lint does not ICE (fixes rust-lang/rust-clippy#11065 (comment)). It *also* makes sure that the expression is not part of a macro call (fixes rust-lang/rust-clippy#11065 (comment)). ~~I'm not sure if there's a better way to check this other than to walk the parent expr chain and see if any of them are expansions.~~ (edit: it doesn't do this anymore) changelog: [`useless_conversion`]: fix ICE when call receiver is a non-fn item changelog: [`useless_conversion`]: don't lint if argument is a macro argument (fixes a FP) r? `@llogiq` (reviewed rust-lang#10814, which introduced these issues)
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Aug 17, 2023
[`useless_conversion`]: only lint on paths to fn items and fix FP in macro Fixes rust-lang#11065 (which is actually two issues: an ICE and a false positive) It now makes sure that the function call path points to a function-like item (and not e.g. a `const` like in the linked issue), so that calling `TyCtxt::fn_sig` later in the lint does not ICE (fixes rust-lang/rust-clippy#11065 (comment)). It *also* makes sure that the expression is not part of a macro call (fixes rust-lang/rust-clippy#11065 (comment)). ~~I'm not sure if there's a better way to check this other than to walk the parent expr chain and see if any of them are expansions.~~ (edit: it doesn't do this anymore) changelog: [`useless_conversion`]: fix ICE when call receiver is a non-fn item changelog: [`useless_conversion`]: don't lint if argument is a macro argument (fixes a FP) r? `@llogiq` (reviewed rust-lang#10814, which introduced these issues)
flip1995
pushed a commit
to flip1995/rust-clippy
that referenced
this issue
Aug 24, 2023
[`useless_conversion`]: only lint on paths to fn items and fix FP in macro Fixes rust-lang#11065 (which is actually two issues: an ICE and a false positive) It now makes sure that the function call path points to a function-like item (and not e.g. a `const` like in the linked issue), so that calling `TyCtxt::fn_sig` later in the lint does not ICE (fixes rust-lang#11065 (comment)). It *also* makes sure that the expression is not part of a macro call (fixes rust-lang#11065 (comment)). ~~I'm not sure if there's a better way to check this other than to walk the parent expr chain and see if any of them are expansions.~~ (edit: it doesn't do this anymore) changelog: [`useless_conversion`]: fix ICE when call receiver is a non-fn item changelog: [`useless_conversion`]: don't lint if argument is a macro argument (fixes a FP) r? `@llogiq` (reviewed rust-lang#10814, which introduced these issues)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
Version
Error output
Backtrace
The text was updated successfully, but these errors were encountered: