It's defined in `rustc_span::source_map` which doesn't make any sense
because it has nothing to do with source maps. This commit moves it to
the crate root, a more sensible spot for something this basic.
It is not necessary to materialize snippets into `String` objects just
to check if they contain comments for example.
changelog: none
r? @blyxyas
(for perf measurements)
The wrong `TypeckResults` was used in the fallback equality function
passed by the `match_same_arms` and `filter_map` lints. Previously,
those fallback functions had no way of using the proper `TypeckResults`.
Those (one per expression being compared) are now passed to the
registered fallback function.
Based on rust-lang/rust-clippy#15978
This will prevent some pointless merge conflict when multiple people add
lints to the same lint pass (e.g. methods).
changelog: None
Fixes https://github.com/rust-lang/rust-clippy/pull/16605
This PR addresses the 6.2% compilation performance regression introduced
by the original `allow_unwrap_types` implementation (which natively
allocated AST strings on every `unwrap` call via `bumpalo`).
The implementation has been refactored to pre-resolve types securely
without a performance penalty:
**Pre-Resolution Cache via `LateLintPass`**: Instead of executing
`ty.to_string()` and `lookup_path_str` inside the immediate
`unwrap_expect_used` hot check for every method call encountered,
`allow-unwrap-types` configuration strings are now parsed exactly *once*
per crate compilation during the `LateLintPass::check_crate` hook in
`clippy_lints/src/methods/mod.rs`.
**`DefId` Native Storage**: The parsed `DefId` representations are
stored in-memory using highly efficient caching maps directly on the
main `Methods` struct:
- `unwrap_allowed_ids: FxHashSet<DefId>`: Allows instant O(1) lookups
for standard types.
- `unwrap_allowed_aliases: Vec<DefId>`: Tracks type aliases requiring
signature substitution checking later.
**Execution Relief**: Inside `unwrap_expect_used::check()`, string
manipulation is completely removed and `ty::Adt` checking uses
lightning-fast `.contains(&adt.did())` operations to categorically avoid
regression allocation loops. This implementation strongly parallels the
pre-resolution type-routing logic in
`clippy_config::types::create_disallowed_map` without altering the core
`clippy.toml` config requirements.
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_SUMMARY_START -->
### Summary Notes
-
[Beta-nomination](https://github.com/rust-lang/rust-clippy/pull/16652#issuecomment-3976671413)
by [samueltardieu](https://github.com/samueltardieu)
*Managed by `@rustbot`—see
[help](https://forge.rust-lang.org/triagebot/note.html) for details*
<!-- TRIAGEBOT_SUMMARY_END -->
<!-- TRIAGEBOT_END -->
changelog: none
`IntoQueryParam` is a trait that lets query callers be a bit sloppy with
the passed-in key.
- Types similar to `DefId` will be auto-converted to `DefId`. Likewise
for `LocalDefId`.
- Reference types will be auto-derefed.
The auto-conversion is genuinely useful; the auto-derefing much less so.
In practice it's only used for passing `&DefId` to queries that accept
`DefId`, which is an anti-pattern because `DefId` is marked with
`#[rustc_pass_by_value]`.
This commit removes the auto-deref impl and makes the necessary sigil
adjustments. (I generally avoid using `*` to deref manually at call
sites, preferring to deref via `&` in patterns or via `*` in match
expressions. Mostly because that way a single deref often covers
multiple call sites.)
rust-lang/rust-clippy#16535
This PR introduces a new configuration option, `allow-unwrap-types`,
which accepts a list of type paths (e.g., `["std::sync::LockResult"]`).
When configured, calling `.unwrap()` or `.expect()` on values of these
types will no longer trigger the `unwrap_used` or `expect_used` lints.
This is particularly useful for reducing noisy lints on patterns where
unwrapping is widely considered acceptable or expected by design, such
as obtaining a `std::sync::LockResult` from `Mutex::lock()`.
**Changes Made**
Introduced the `allow_unwrap_types: Vec<String>` field in
`clippy_config`.
Updated the `unwrap_expect_used` lint to check the underlying evaluated
expression `ty` against the configured allowed types.
Handled robust type alias resolution so that aliases like
`std::sync::LockResult` accurately map to their underlying `Adt` types
during lint evaluation.
Added UI tests in `tests/ui-toml/unwrap_used_allowed/` to verify both
allowed and disallowed cases.
----
changelog: [`unwrap_used`], [`expect_used`]: Add `allow-unwrap-types`
configuration to allow unwrapping specified types.
To be honest, the changes are confusing.
First of all, it has already been stated that it would be wrong if we
extended the lint to cover both sides.
https://github.com/rust-lang/rust-clippy/blob/18e5b2db4a3f9de20aa472d5c46a855e3a31d5c4/tests/ui/unnecessary_fold.rs#L91-L95
Secondly, there is some monstrous expression in the
`get_triggered_expr_span` function, and I think it could be rewritten
more cleanly.
Anyway, even if it has to be implemented, I'm glad to rewrite it more
thoroughly.
Fixesrust-lang/rust-clippy#16581.
----
changelog: [`unnecessary_fold`]: match against an accumulator on both
sides.
Fixes: rust-lang/rust-clippy#16555
changelog: [unnecessary_min_or_max]: Fix false negatives for
usize::{MIN,MAX} by handling usize bit width correctly during constant
evaluation, enabling the lint to trigger on cases like n.min(0) /
n.max(usize::MAX).
Now, only `call_span` is replaced, so the receiver is not a part of the
diff. This also removes the need to create a snippet for the receiver.
changelog: [`str_split`]: reduce suggestion diff
Linshu Yang