Currently the `sugg` utility treats all `ExprKind::Match` expressions as
potentially needing brackets, and therefore many lints will add
parenthesis around them. However this includes desugared match
expressions like the `?` and `.await` operators.
In this PR I have updated the utility to only treat match expressions
which include a code block as needing parenthesis, as the other types
have similar precedence rules and expectations to things like member
access and I think can be treated like as such.
While this change is small on paper it touches a large amount of code
due to changing a cross cutting concern, I am happy to add additional
tests if we think it is needed, but I wanted to get a feel for if this
is even a sensible change to be doing and what the expectations were
around the level of testing needed before investing more time into it.
Regarding not putting a specific lint in the changelog, determining all
the lints this could possibly effect would be possible but take some
time, and I wonder if it would be a bit too noisy in the changelog. Open
to suggestions about how best to address that.
fixesrust-lang/rust-clippy#16045
changelog: stop inserting unnecessary brackets around `x?` and `x.await`
expressions in suggestions
Inherent const impl
Some constifications are annoying because we need to repeat `T: Trait` bounds from an impl block on the individual constified `const fn`s as `T: [const] Trait`. We've brainstormed solutions before, and one would be to have separate `const impl` blocks or sth. However the final syntax will look, I decided to just impl this syntax and either have sth nice on nightly to work with or at least move the discussion along.
Also interacts with the discussion around `impl const Trait for Type` vs `const impl Trait for Type`, as we may want to use the latter to keep inherent and trait impls in sync (unless we come up with even another scheme).
* [ ] rustdoc + tests
* [ ] macro stability /regression tests
r? `@fee1-dead`
cc `@traviscross` `@rust-lang/project-const-traits`
- move `is_allowed_vec_method` (a stripped-down version of it, anyway,
as the function doesn't make sense as is out of context) to utils, as
it's shared between `useless_vec` and `ptr_arg`
- add another test for non-standard macro brace case
- rm unneeded `allow`s
- rm duplicated tests
- add comments to some tests
Add `overflow_checks` intrinsic
This adds an intrinsic which allows code in a pre-built library to inherit the overflow checks option from a crate depending on it. This enables code in the standard library to explicitly change behavior based on whether `overflow_checks` are enabled, regardless of the setting used when standard library was compiled.
This is very similar to the `ub_checks` intrinsic, and refactors the two to use a common mechanism.
The primary use case for this is to allow the new `RangeFrom` iterator to yield the maximum element before overflowing, as requested [here](https://github.com/rust-lang/rust/issues/125687#issuecomment-2151118208). This PR includes a working `IterRangeFrom` implementation based on this new intrinsic that exhibits the desired behavior.
[Prior discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Ability.20to.20select.20code.20based.20on.20.60overflow_checks.60.3F)
mgca: Add ConstArg representation for const items
tracking issue: rust-lang/rust#132980fixesrust-lang/rust#131046fixesrust-lang/rust#134641
As part of implementing `min_generic_const_args`, we need to distinguish const items that can be used in the type system, such as in associated const equality projections, from const items containing arbitrary const code, which must be kept out of the type system. Specifically, all "type consts" must be either concrete (no generics) or generic with a trivial expression like `N` or a path to another type const item.
To syntactically distinguish these cases, we require, for now at least, that users annotate all type consts with the `#[type_const]` attribute. Then, we validate that the const's right-hand side is indeed eligible to be a type const and represent it differently in the HIR.
We accomplish this representation using a new `ConstItemRhs` enum in the HIR, and a similar but simpler enum in the AST. When `#[type_const]` is **not** applied to a const (e.g. on stable), we represent const item right-hand sides (rhs's) as HIR bodies, like before. However, when the attribute is applied, we instead lower to a `hir::ConstArg`. This syntactically distinguishes between trivial const args (paths) and arbitrary expressions, which are represented using `AnonConst`s. Then in `generics_of`, we can take advantage of the existing machinery to bar the `AnonConst` rhs's from using parent generics.
When mgca is enabled, const rhs's that are paths may have false
negatives with the lints in non_copy_const.rs. But these should probably
be using the trait solver anyway, and it only happens under mgca.
Implement pin-project in pattern matching for `&pin mut|const T`
This PR implements part of rust-lang/rust#130494. It supports pin-project in pattern matching for `&pin mut|const T`.
~Pin-projection by field access (i.e. `&pin mut|const place.field`) is not fully supported yet since pinned-borrow is not ready (rust-lang/rust#135731).~
CC ``````@traviscross``````
Constify trait aliases
Allow `const trait Foo = Bar + [const] Baz;` trait alias declarations. Their rules are the same as with super traits of const traits. So `[const] Baz` or `const Baz` is only required for `[const] Foo` or `const Foo` bounds respectively.
tracking issue rust-lang/rust#41517 (part of the general trait alias feature gate, but I can split it out into a separate const trait alias feature gate. I just assumed that const traits would stabilize before trait aliases, and we'd want to stabilize trait aliases together with const trait aliases at the same time)
r? ``@compiler-errors`` ``@fee1-dead``
Mark desugared range expression spans with DesugaringKind::RangeExpr
This is a prerequisite to removing `QPath::LangItem` (rust-lang/rust#115178) because otherwise there would be no way to detect a range expression in the HIR.
There are some non-obvious Clippy changes so a Clippy team review would be good.
Previously the program only fixed the code when the closure supplied to
the method contained only 1 line. This patch removes the restriction.
The code already works. This patch only removes the extra check that
causes the restriction. The test cases that can now be fixed are moved
into the files containing tests cases that can be fixed.
The unnecessary check has survived in the code this way.
- In Dec 2015, patch a6bd2d0622, pull request 524. The lint was first
added. The program did not support fixing code automatically yet. So
the suggested fix was printed as a part of the diagnostic message.
When the original code contained multiple lines, the suggested fix was
omitted in order to keep the diagnostic message concise.
- In May 2019, patch bd0b75f6c3, pull request 4049. Logic was added
to strip the reference in the closure when the suggested replacement
method required it. Because the fix was still only printed when the
code contained a single line, the new transformation was only done
when the code contained a single line.
- In Aug 2019, patch 945d4cf69f, pull request 4454. The lint was
updated to fix code automatically. Because the fixed code had only
been printed in the diagnostic message for a single line, the fix was
only added for a single line.
- In Nov 2021, patch 092fe209a6, pull request 7463. The logic for
transforming the closure was moved into another file. A comment was
added saying that it was only good for a single line because it had
only been used for a single line.
changelog: [`search_is_some`] now fixes code spanning multiple lines
Philipp Krones