cc @GuillaumeGomez
- Searching/filtering no longer creates a new history entry per
keystroke/change
- Loading a URL with a specified search query now works. The search is
now stored as `?search=foo` instead of `#/foo`, not a breaking change
since this didn't work before
- The browser back/forward actions now update the filters/search and
displayed lints
The bulk of the changes are to support that last one, previously the
filter state was stored both in the DOM and as JS objects. The DOM is
now the single source of truth
changelog: none
cc rust-lang/rust#148190 @flip1995 @RalfJung
This is a bit of a hack in that it hardcodes the list of crates with
stability attributes. This shouldn't be a big deal since that isn't a
set that changes very frequently and an internal lint could detect when
that happens.
The `fixme`s added aren't new issues and shouldn't get in the way of
unblocking the upstream issue.
changelog: none
Add new `function_casts_as_integer` lint
The `function_casts_as_integer` lint detects cases where users cast a function pointer into an integer.
*warn-by-default*
### Example
```rust
fn foo() {}
let x = foo as usize;
```
```
warning: casting a function into an integer implicitly
--> $DIR/function_casts_as_integer.rs:9:17
|
LL | let x = foo as usize;
| ^^^^^^^^
|
help: add `fn() as usize`
|
LL | let x = foo as fn() as usize;
| +++++++
```
### Explanation
You should never cast a function directly into an integer but go through a cast as `fn` first to make it obvious what's going on. It also allows to prevent confusion with (associated) constants.
Related to https://github.com/rust-lang/rust/issues/81686 and https://stackoverflow.com/questions/68701177/whats-the-meaning-of-casting-a-rust-enum-variant-to-a-numeric-data-type
r? ````@urgau````
Workspaces don't have their integration tests in tests/ at the root, so
this check missed them.
This fixesrust-lang/rust-clippy#11775 for workspaces.
changelog: [`mod_module_files`]: Fix false positive for integration
tests in workspace crates.
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.
- reduce indentation
- print constructor/method name in backticks
changelog: [`unnecessary_map_on_constructor`]: print constructor/method
name in backticks
It's always a bit jarring to be required to provide the expected output
first, as usually one starts with having the existing output, and
modifies that.
This commit reorders the two steps, and also gives them the same names
as `rust-lang/rust` for some extra consistency
changelog: none
It's always a bit jarring to be required to provide the expected output
first, as usually one starts with having the existing output, and
modifies that.
This commit reorders the two steps, and also gives them the same names
as `rust-lang/rust` for some extra consistency
