For some reason we had them in some projects, I'm not sure why. But this caused cache priming to appear stuck - because it uses a set of crate IDs for the actual work, but for the number of crates to index it just uses `db.all_crates().len()`.
Based on rust-lang/rust-clippy#13223
Various refactoring on `clippy_dev` before upgrading rename and
splitting `clippy_lints` into multiple crates.
Some improvements:
* The working directory is set to the root clippy directory. Running
from a subdirectory was kind of supported before sometimes. Now it just
works.
* File won't be written unless they're actually updated. Most of the
time they weren't written, but a few cases slipped through.
* Buffers are reused more for the negligible speed boost.
changelog: None
MaybeUninit::write: fix doc
# Fix doc for `MaybeUninit::write`
The documentation refers to the way `MaybeUninit` stores data internally. The property of not dropping content on context exit is the responsibility of `ManuallyDrop`.
Add an issue template for future-incompatible lints
This adds a GitHub issue template for future-incompatible lints. Most of the existing tracking issues have been using different formats with different information, and I think it would be helpful to make them a little more consistent and to ensure that sufficient information is provided.
Some comments on my choices:
* Added a dedicated section to describe *why* the change is being made. Many existing issues already have this, so let's standardize on it.
* Have a section with a very clear example. Almost all of the existing issues have this in one form or another.
* Added a "Recommendations" section, since this is something I see missing in several of the existing issues, and this is really important information IMHO.
* I reworded the "When" section. The existing template mentioned that these get reviewed every 6 weeks which my understanding is not true. That's also not very helpful information to the user, since it doesn't really answer the question. I'm not sure this section will actually be useful since I suspect most of the time we don't know when it will change (there have been a few exceptions).
* Clearly show the expected progression steps. Several issues already have this.
* Added implementation history, which is useful for linking PRs. (IDK, this could get merged with "Steps".)
The previous commit moved all test files from `std` to `core` so git
understands the move. Not all functionality is actually testable in
`core`, however, so perform move the relevant portions back. Changes
from inherent to module methods is also done since this is the form of
math operations available in `core` (as `core_float_math`).
The reasons I'm doing it is that
* merging those blocks allows for more parallelism as you don't run parallel blocks in sequence
* merging blocks allows merging analysis queries shrinking the dep graph
* should allow us to do more early aborting in case of errors and/or moving query calls from the analysis query into others that allow early aborting the others (and doing more tainting and stuff)
When a `non_std_lazy_statics` warning is generated about an item type
which can be replaced by a standard library one, ensure that the lint
happens on the item HIR node so that it can be expected.
changelog: [`non_std_lazy_statics`]: generate the warning onto the right
node
Fixesrust-lang/rust-clippy#14729
Note that this doesn't change anything on lints generated for the
`lazy_static::lazy_static` macro because the `expect` attribute cannot
be applied to a macro.
Many float-related tests in `std` only depend on `core`, so move the
tests there. This also allows us to verify functions from
`core_float_math`.
Since the majority of test files need to be moved to `coretests`, move
the files here without any cleanup; this is done in a followup commit.
This makes git history slightly cleaner, but coretests will not build
immediately after this commit.
Since [1], `compiler-builtins` makes a certain set of math symbols
weakly available on all platforms. This means we can begin exposing some
of the related functions in `core`, so begin this process here.
It is not possible to provide inherent methods in both `core` and `std`
while giving them different stability gates, so standalone functions are
added instead. This provides a way to experiment with the functionality
while unstable; once it is time to stabilize, they can be converted to
inherent.
For `f16` and `f128`, everything is unstable so we can move the inherent
methods.
The following are included to start:
* floor
* ceil
* round
* round_ties_even
* trunc
* fract
* mul_add
* div_euclid
* rem_euclid
* powi
* sqrt
* abs_sub
* cbrt
These mirror the set of functions that we have in `compiler-builtins`
since [1].
Tracking issue: https://github.com/rust-lang/rust/issues/137578
[1]: https://github.com/rust-lang/compiler-builtins/pull/763
