[never_loop] Fix#10304
It is not sufficient to ignore break from a block inside the loop. Instructions after the break must be ignored, as they are unreachable. This is also true for all instructions in outer blocks and loops until the right block is reached.
Fixes#10304
---
changelog: FP: [`never_loop`]: No longer lints, for statements following break statements for outer blocks.
[#10311](https://github.com/rust-lang/rust-clippy/pull/10311)
<!-- changelog_checked-->
interpret: rename Pointer::from_addr → from_addr_invalid
This function corresponds to `ptr::invalid` in the standard library; the previous name was not clear enough IMO.
Use derive attributes for uninteresting traversals
It appears that visiting and folding was implemented on `BitMatrix` solely so that the derive macros could be used on `GeneratorLayout`, however such implementation would not necessarily be correct for other uses (if there were any). Adding attributes to the derive macro is more correct and potentially more generally useful.
r? ``@oli-obk``
Refactor refcounted structural_impls via functors
The mapping of values in refcounted types can be extracted as a functor, simplifying the implementations in the type library (whose structural folding impls now all use such functors). This functor could also prove more generally useful elsewhere.
add an unstable `#[rustc_coinductive]` attribute
useful to test coinduction, especially in the new solver.
as this attribute should remain permanently unstable I don't think this needs any official approval. cc ``@rust-lang/types``
had to weaken the check for stable query results in the solver to prevent an ICE if there's a coinductive cycle with constraints.
r? ``@compiler-errors``
Store metrics from `metrics.json` to CI PGO timer
With this change, we'll be able to easily see how long does it take to compile LLVM vs `rustc`.
r? ```@Mark-Simulacrum```
Update the minimum external LLVM to 14
With this change, we'll have stable support for LLVM 14 through 16 (pending release).
For reference, the previous increase to LLVM 13 was #100460.
Rollup of 10 pull requests
Successful merges:
- #103478 ( Suggest fix for misplaced generic params on fn item #103366 )
- #107739 (Check for overflow in evaluate_canonical_goal)
- #108003 (Avoid ICE when the generic_span is empty)
- #108016 ("Basic usage" is redundant for there is just one example)
- #108023 (Shrink size of array benchmarks)
- #108024 (add message to update Cargo.toml when x is changed)
- #108025 (rustdoc: add more tooltips to intra-doc links)
- #108029 (s/eval_usize/eval_target_usize/ for clarity)
- #108035 (Avoid using a dead email address as the main email address)
- #108038 (Remove needless supertrait constraints from Interner projections)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove needless supertrait constraints from Interner projections
These associated types are already all constrained to implement `Ord`, so specifically requiring its supertraits `Eq`, `PartialEq` and `PartialOrd` is superfluous.
Avoid using a dead email address as the main email address
This caused highfive to welcome me as a new contributor on every PR, because it couldn't find any commits of mine.
Suggest fix for misplaced generic params on fn item #103366fixes#103366
This still has some work to go, but works for 2/3 of the initial base cases described in #1033366
simple fn:
```
error: expected identifier, found `<`
--> shreys/test_1.rs:1:3
|
1 | fn<T> id(x: T) -> T { x }
| ^ expected identifier
|
help: help: place the generic parameter list after the function name:
|
1 | fn id<T>(x: T) -> T { x }
| ~~~~
```
Complicated bounds
```
error: expected identifier, found `<`
--> spanishpear/test_2.rs:1:3
|
1 | fn<'a, B: 'a + std::ops::Add<Output = u32>> f(_x: B) { }
| ^ expected identifier
|
help: help: place the generic parameter list after the function name:
|
1 | fn f<'a, B: 'a + std::ops::Add<Output = u32>>(_x: B) { }
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Opening a draft PR for comments on approach, particularly I have the following questions:
- [x] Is it okay to be using `err.span_suggestion` over struct derives? I struggled to get the initial implementation (particularly the correct suggestion message) on struct derives, although I think given what I've learned since starting, I could attempt re-doing it with that approach.
- [x] in the case where the snippet cannot be obtained from a span, is the `help` but no suggestion okay? I think yes (also, when does this case occur?)
- [x] are there any red flags for the generalisation of this work for relevant item kinds (i.e. `struct`, `enum`, `trait`, and `union`). My basic testing indicates it does work for those types except the help tip is currently hardcoded to `after the function name` - which should change dependent on the item.
- [x] I am planning to not show the suggestion if there is already a `<` after the item identifier, (i.e. if there are already generics, as after a function name per the original issue). Any major objections?
- [x] Is the style of error okay? I wasn't sure if there was a way to make it display nicer, or if thats handled by span_suggestion
These aren't blocking questions, and I will keep working on:
- check if there is a `<` after the ident (and if so, not showing the suggestion)
- generalize the help message
- figuring out how to write/run/etc ui tests (including reading the docs for them)
- logic cleanups
