Fixesrust-lang/rust-clippy#5955
I understand that there's a feature freeze right now. I had started
working on this before I was aware of the feature freeze. I don't mind
waiting as long as I need to for feedback.
changelog: [`same_length_and_capacity`]: adds a new lint that checks for
usages of `from_raw_parts` where the same expression is passed for the
length and the capacity
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_SUMMARY_START -->
### Summary Notes
-
[Feature-freeze](https://github.com/rust-lang/rust-clippy/pull/15656#issuecomment-3276620004)
by [github-actions[bot]](https://github.com/github-actions[bot])
*Managed by `@rustbot`—see
[help](https://forge.rust-lang.org/triagebot/note.html) for details*
<!-- TRIAGEBOT_SUMMARY_END -->
<!-- TRIAGEBOT_END -->
This commit is put before the one that actually introduces the lint,
since, were they put in the opposite order, the first commit wouldn't
pass dogfood
Fixesrust-lang/rust-clippy#16061.
Extend `never_loop` to also lint iterator reduction methods (e.g.
`for_each`, `try_for_each`, `fold`, `try_fold`, `reduce`, `all`, `any`)
when the closure’s body diverges (return type `!`). Add a UI test
`never_loop_iterator_reduction` to cover these cases.
Testing:
- TESTNAME=never_loop_iterator_reduction cargo uitest
changelog: [`never_loop`]: lint diverging iterator reduction closures
like `for_each` and `fold`
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``````
llogiq