Only the end bounds of ranges can actually be included or excluded. This
commit changes the SpannedRange type to reflect that. Update `Kind::value`
to and `Kind::cmp` for this change. `Kind::cmp` gets flipped to check value
first and then the bound details and is much shorter.
This unbounded case never actually happens because `all_ranges(..)` uses
the scrutinee type bounds for open ranges. Switch to our own `Bound`
enum so that we don't have this case.
Introduce `expr_visitor` and `expr_visitor_no_bodies`
changelog: none
A couple utils that satisfy a *lot* of visitor use cases. Factoring in every possible usage would be really big so I just focused on cleaning clippy_utils.
The only reason to use `abort_if_errors` is when the program is so broken that either:
1. later passes get confused and ICE
2. any diagnostics from later passes would be noise
This is never the case for lints, because the compiler has to be able to deal with `allow`-ed lints.
So it can continue to lint and compile even if there are lint errors.
TraitKind -> Trait
TyAliasKind -> TyAlias
ImplKind -> Impl
FnKind -> Fn
All `*Kind`s in AST are supposed to be enums.
Tuple structs are converted to braced structs for the types above, and fields are reordered in syntactic order.
Also, mutable AST visitor now correctly visit spans in defaultness, unsafety, impl polarity and constness.
Add `cargo dev lint` to manually run clippy on a file
I found the manual run command really useful, this makes it a bit easier to type
Not sure if this belongs in the changelog or not
changelog: Add `cargo dev lint` to manually run clippy on a file
Replace `in_macro` usage with `from_expansion`
changelog: none
Generally replace `in_macro(span)` with `span.from_expansion()`. If we're just trying to avoid expanded code, this seems more appropriate because any kind of expanded code is prone to false positives. One place I did not touch is `macro_use.rs`. I think this lint could use a rewrite so I moved `in_macro` there, the only place it is still used.
Reference `clippy_utils` docs on nightly-rustc and some other documentation updates
The `clippy_utils` crate is now part of the nightly-rustc documentation. See [**very beautiful documentation**](https://doc.rust-lang.org/nightly/nightly-rustc/clippy_utils/). This PR references them in our documentation and updates some other documentation.
changelog: none
[beta] Backport: Move if_then_panic to pedantic and rename to manual_assert
Backport of #7810
cc `@camsteffen`
r? `@ghost`
changelog: none (same release)
Update Clippy dependencies
Clippy has two outdated dependencies, where one indirect dependency has been flagged by rustsec for dropping a lifetime. See [RUSTSEC-2020-0146](https://rustsec.org/advisories/RUSTSEC-2020-0146). This PR updates these dependencies.
With previous dependency updates, it was tried to prevent duplicates in the `Cargo.lock` file of rust-lang/rust. I've tried to keep this in mind with this update.
* Dependency `semver`
* Used in `src/tools/cargo/Cargo.toml` as version `1.0.3`
* Used in `src/tools/rust-analyzer/crates/project_model/Cargo.toml` as version `1`
* Updated in Clippy from `0.11` to `1.0` (Clippy usually defines the major and minor patch version). The `Cargo.lock` file lists `1.0.3` which is one patch version behind the most recent one but prevents a duplicate with cargo's pinned version.
* Dependency `cargo_metadata`
* Used in several tools as `0.14`
* Used in `src/tools/tidy` and `src/tools/rls` as `0.12`
* Updated in Clippy from `0.12` to `0.14`
All updates to the `Cargo.lock` have been done automatically by `x.py`.
There are still some tools with these outdated dependencies. Clippy didn't require any changes, and it would be likely that the others could also be updated without any problem. Let me know if I should try to update them as well 🙃.
Keep up the good work, whoever is reading this 🦀
---
For Clippy:
changelog: none
Use .cargo/config.toml instead of .cargo/config
`.cargo/config.toml` is the preferred form for the local configuration file. This is emphasized in _The Cargo Book_ with the following note:
> Note: Cargo also reads config files without the `.toml` extension, such as `.cargo/config`. Support for the `.toml` extension was added in version 1.39 and is the preferred form.
Moreover, this helps with toml-aware text editors as they will recognize the file extension.
changelog: none
`.cargo/config.toml` is the preferred form for the local configuration
file. This is emphasized in _The Cargo Book_ with the following note:
> Note: Cargo also reads config files without the `.toml` extension, such
> as `.cargo/config`. Support for the `.toml` extension was added in version
> 1.39 and is the preferred form.
Moreover, this helps with toml-aware text editors as they will recognize
the file extension.
