Open antonilol opened 1 month ago
I have an interest for this issue.
Currently, we are looking at Option and Result types, so this behavior appears to be the case.
Is it OK to add a new pattern? I'm concerned that this rule will grow big, as I feel there are multiple other operations that can panic.
This is intentional. Linting on index expressions will result in a lot of false positives. Most of the time indexing is used in a way that either can't panic, or the function's implementation has a bug if it does. Since neither of those cases should lint, and we have no way to discern them from cases which should, we err on the side of false negatives for these.
If anyone can come up with a decent heuristic for this that would be considered.
I thought this lint would search for places that could panic and missed this one, but it is just a list of methods and macros. unwrap_err()
will not trigger it and rewriting res.unwrap()
to Result::unwrap(res)
will also cause it to not trigger anymore.
Should this recursively search for functions that can panic and have some filter to exclude common operations that can panic but are 'allowed' (like slicing)?
Intra-function lints are generally not a thing we do in clippy as it's easy to make them add a fair bit to the runtime. In this case scanning the entire call graph for panics will result in an incredible false-positive rate. It's easy to call a function which can panic, but will never under the circumstances it's called in.
Summary
missing_panics_doc
does not trigger on indexing, which could panic..get(...).unwrap()
is equivalent and does get caught.Lint Name
missing_panics_doc
Reproducer
I tried this code:
I expected to see this happen: warnings on both a and b
Instead, this happened: warning only on b
Version