Generic lint catching any AST that matches functions in stdlib

[nyurik]

Would it be possible search user code using AST-style pattern rather than implementing lint search logic by hand (where it makes sense)?

This is similar to what ast-grep does, except that the actual search patterns would come from the existing stdlib functions, plus ideally it should be after the type resolution.

This way #16166 and similar lints would not even be needed. I do suspect there will be a significant number of false-positives which may need some way to be excluded.

Example

User code looks identical to what Slice::get does, so it would be found automatically without creating a specific lint:

pub static GLOBAL_ARRAY: [&str; ...] = [...];

fn get_item(index: usize) -> Option<&'static str> {
  if index < GLOBAL_ARRAY.len() {
    Some(GLOBAL_ARRAY[index])
  } else {
    None
  }
}

[Alexendoo]

Stdlib functions usually contain some levels of abstraction/optimisation that a manual impl would not

e.g. slice.get() has both - it goes through SliceIndex, the usize/slice impl of which calls an intrinsic to do the indexing rather than the index operator

[nyurik]

that's a good observation, thx. I was thinking of all the utility functions too, e.g. in Option, Result, etc. But I guess doing "dynamic" clippy lint generation based on stdlib is a bit of a moving target...

That said, perhaps this approach may help simplify some lints -- instead of the complex chained if let statements, store some of the common lints as quote! token tree (or similar). I guess this will bring ast-grep even closer aligned with what Clippy does internally. This will improve maintainability of Clippy lints, and will lower the barrier of adding new ones...

[y21]

This sounds a bit similar to the syntax tree patterns RFC (#3875), which would let you declare the ast pattern to look for in a bit more high level way and decouples it from rustc (although most lints will still need a lot of extra manual checks, which is fine with this because it lets you extract things from the ast and check it afterwards). It's an interesting idea but has never been implemented to my knowledge