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
It's common to import dependencies from the sysroot via `extern crate`
rather than use an explicit cargo dependency, when it's necessary to use
the same dependency version as used by rustc itself. However, this is
dangerous for crates.io crates, since rustc may not pull in the
dependency on some targets, or may pull in multiple versions. In both
cases, the `extern crate` fails to resolve.
To address this, re-export all such dependencies from the appropriate
`rustc_*` crates, and use this alias from crates which would otherwise
need to use `extern crate`.
- Move it and its helper function `parse_attrs` together to the end
of the file, because it's surprising to see front-and-center a struct
that's only really used in one place (`cognitive_complexity`).
- Avoid panic path in `LimitStack::limit`
- Replace `assert` with `debug_assert` to avoid panics in release builds
This lint aims at detecting unusual names used in Clippy source code,
such as `appl` or `application` for a `rustc_errors::Applicability`
variable, instead of `app` and `applicability` which are commonly used
throughout Clippy.
This helps maintaining the consistency of the Clippy source code.
Philipp Krones