If there are more than one dereference (there is one corresponding
matched with a borrow in any case), consider that the argument might
point to a place expression, which is the safest choice.
Also, use an appropriate number of dereferences in suggestions involving
arguments using themselves multiple dereferences.
Fixesrust-lang/rust-clippy#15166
changelog: [`swap_with_temporary`]: fix false positive leading to
different semantics being suggested, and use the right number of
dereferences in suggestion
r? y21
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_SUMMARY_START -->
### Summary Notes
-
[beta-nomination](https://github.com/rust-lang/rust-clippy/pull/15172#issuecomment-3016752569)
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 -->
Closesrust-lang/rust-clippy#15163
This lint should not give suggestions in const context for now, since a
lot of the commonly used method of `Result` is not const.
changelog: [`cast_possible_truncation`] fix improperly give suggestions
inside const context
If there are more than one dereference (there is one corresponding
matched with a borrow in any case), consider that the argument might
point to a place expression, which is the safest choice.
Also, use an appropriate number of dereferences in suggestions involving
arguments using themselves multiple dereferences.
Closesrust-lang/rust-clippy#15116
The cause for this issue is that `_` belongs to the `Common` catagory in
unicode instead of `Latin` like other ASCII alphabets. Since ASCII
characters are always allowed, I just added an extra `is_ascii()` check
to ensure this.
changelog: [`disallowed_script_idents`] fix FP on identifiers with `_`
The lint was extra restrictive, and didn't suggest using
`core::ptr::null` and `core::ptr::null_mut` in `const` contexts although
they have been const-stabilized since Rust 1.24.
changelog: [`zero_ptr`]: lint in `const` context as well
@rustbot label +I-false-negative +C-bug
The lint was extra restrictive, and didn't suggest using
`core::ptr::null` and `core::ptr::null_mut` in `const` contexts although
they have been const-stabilized since Rust 1.24.
I expect that most people use stable Clippy. So having `master` be the
first documentation link in the list is weird. Now the versions are
sorted stable->beta->master.
changelog: none
I expect that most people use stable Clippy. So having `master` be the first
documentation link in the list is weird. Now the versions are sorted
stable->beta->master.
This PR announces the feature freeze period talked about in
https://github.com/rust-lang/rust-clippy/issues/14364
1. Add the page to the book
2. Modify the in-Github templates.
3. The third commit (to be squashed into the first) rolls the date
mentioned 6 weeks (so, starting on May 9th and ending on August 20th).
This gives us a comfortable buffer to make choices for this period.
We have a pending discussion on the #14364. So having some more time to
make choices is very nice. I'm also preparing a Github action for
detecting new lints and posting a comment about the feature freeze
(being worked on in another branch)
Something I'd like comment on is the date formatting. I'm not sure if
"May 9th to the first of August" is the correct way of writing this
information in a book 😅.
changelog: Announce the feature freeze from May 9th to the first of
August
update to literal-escaper 0.0.4 for better API without `unreachable` and faster string parsing
This is the replacement for just the part of https://github.com/rust-lang/rust/pull/138163 dealing with the changed API of unescape functionality, since that got moved into its own crate.
<del>This uses an unpublished version of literal-escaper (https://github.com/rust-lang/literal-escaper/pull/8).</del>
r? `@nnethercote`
Violets are red,
Roses are blue,
Summer’s a feeling,
And we’re feeling it too.
<hr>
> (Please ping me when June made it as the cat of the release. I want to
send it to her owner :D)
@xFrednet voila:
Cats for the next release can be traditionally nominated in the comments
:D
Please be more active and cat-minded 😻
<hr>
changelog: none
r? flip1995
In `wildcard_enum_match_arm`, expanding a variant with struct-like
fields was missing a space between the variant name and the opening
bracket.
Also, add a test for tuple-like variants with only one field, as those
are expanded as `VariantName(_)` instead of `VariantName(..)`.
changelog: none
In `wildcard_enum_match_arm`, expanding a variant with struct-like
fields was missing a space between the variant name and the opening
bracket.
Also, add a test for tuple-like variants with only one field, as those
are expanded as `VariantName(_)` instead of `VariantName(..)`.
Closesrust-lang/rust-clippy#15091
The lack of ability to escape raw identifiers is a known issue of
Clippy. In this case, it can be avoided by snippet from the code.
changelog: [`wildcard_enum_match_arm`] fix wrong suggestions with raw
identifiers
Fixesrust-lang/rust-clippy#14789
changelog: [`redundant_closure`],
[`redundant_closure_for_method_calls`]: allow lint to be allowed or
expected on the closure expression itself
Add diagnostic items for Clippy
Clippy still uses some paths to access items from the standard library. Adding the missing diagnostic items allows removing the last remaining paths.
Closesrust-lang/rust-clippy#5393
If a reborrow is itself borrowed mutably, do not propose to replace it
by the original reference.
Fixes: rust-lang/rust-clippy#14934
changelog: [`borrow_deref_ref`]: do not propose replacing a reborrow by
the original reference if the reborrow is itself mutably borrowed
For example, adding `*` in front of `*expression` is best shown as
`**expression` rather than `*(*expression)`.
This is not perfect, as it checks whether the operator is already a
prefix of the expression, but it is better than it was before. For
example, `&`+`&mut x` will get `&&mut x` but `&mut `+`&x` will get `&mut
(&x)` as it did before this change.
changelog: none
Optimize `needless_doctest_main`, make it short-circuit, make sure that
we don't spin up a new compiler on EVERY code block.
---
The old implementation was creating a new compiler, new parser, new
thread, new SessionGlobals, new everything for each code block. No
matter if they actually didn't even contain `fn main()` or anything
relevant.
On callgrind, seems that we're reducing about a 6.7242% de cycle count
(which turns out to be a 38 million instruction difference, great!).
Benchmarked in `bumpalo-3.16.0`. Also on bumpalo we spawn 78 less
threads. This moves `SessionGlobals::new` from the top time-consuming
function by itself in some benchmarks, into one not even in the top 500.
Also, populate the test files.
changelog:[`needless_doctest_main`]: Avoid spawning so many threads in
unnecessary circumstances
