When encountering a move error on a value within a loop of any kind,
identify if the moved value belongs to a call expression that should not
be cloned and avoid the semantically incorrect suggestion. Also try to
suggest moving the call expression outside of the loop instead.
```
error[E0382]: use of moved value: `vec`
--> $DIR/recreating-value-in-loop-condition.rs:6:33
|
LL | let vec = vec!["one", "two", "three"];
| --- move occurs because `vec` has type `Vec<&str>`, which does not implement the `Copy` trait
LL | while let Some(item) = iter(vec).next() {
| ----------------------------^^^--------
| | |
| | value moved here, in previous iteration of loop
| inside of this loop
|
note: consider changing this parameter type in function `iter` to borrow instead if owning the value isn't necessary
--> $DIR/recreating-value-in-loop-condition.rs:1:17
|
LL | fn iter<T>(vec: Vec<T>) -> impl Iterator<Item = T> {
| ---- ^^^^^^ this parameter takes ownership of the value
| |
| in this function
help: consider moving the expression out of the loop so it is only moved once
|
LL ~ let mut value = iter(vec);
LL ~ while let Some(item) = value.next() {
|
```
We use the presence of a `break` in the loop that would be affected by
the moved value as a heuristic for "shouldn't be cloned".
Fix#121466.
Previously, when passing lint rules manually using `x clippy ..`, ignored lints would
override manual ones. This change corrects the order by passing ignored lints after the
manual ones.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
We need to keep the order of the given clippy lint rules before passing them.
Since clap doesn't offer any useful interface for this purpose out of the box,
we have to handle it manually.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Rollup of 6 pull requests
Successful merges:
- #120640 (Mark UEFI std support as WIP)
- #121862 (Add release notes for 1.77.0)
- #122572 (add test for #122301 to cover behavior that's on stable)
- #122578 (Only invoke `decorate` if the diag can eventually be emitted)
- #122615 (Mention Zalathar for coverage changes)
- #122636 (some minor code simplifications)
r? `@ghost`
`@rustbot` modify labels: rollup
Mark UEFI std support as WIP
Currently stdio and alloc support is present with open PRs for some of the other portions.
A prototype of almost all of std support can be found [here](https://github.com/tianocore/rust/tree/uefi-master). I will be up-streaming as much stuff as possible from there.
run change tracker even when config parse fails
Please note that we are currently validating the build configuration on two entry points (e.g., profile validation is handled on the python side), and change tracker system is handled on the rust side. Once #94829 is completed (scheduled for 2024), we will be able to handle this more effectively.
Fixes#121756
Don't show suggestion if slice pattern is not top-level
Close#120605
Don't show suggestion to add slicing (`[..]`) if the slice pattern is enclosed by struct like `Struct { a: [] }`.
For example, current rustc makes a suggestion as a comment. However, the pattern `a: []` is wrong, not scrutinee `&self.a`.
In this case, the structure type `a: Vec<Struct>` and the pattern `a: []` are different so I think the pattern should be fixed, not the scrutinee.
If the parent of the pattern that was the target of the error is a structure, I made the compiler not show a suggestion.
```rs
pub struct Struct {
a: Vec<Struct>,
}
impl Struct {
pub fn test(&self) {
if let [Struct { a: [] }] = &self.a {
// ^^^^^^^^^^^^^^^^^^ ------- help: consider slicing here: `&self.a[..]`
println!("matches!")
}
}
}
```
Note:
* ~~I created `PatInfo.history` to store parent-child relationships for patterns, but this may be inefficient.~~
* I use two fields `parent_kind` and `current_kind` instead of vec. It may not performance issue.
* Currently only looking at direct parents, but may need to look at deeper ancestry.
Rollup of 5 pull requests
Successful merges:
- #119411 (Add as_(mut_)ptr and as_(mut_)slice to raw array pointers)
- #122248 (Respect stage0 sysroot when compiling rmake.rs with COMPILETEST_FORCE_STAGE0)
- #122295 (mir-opt: always run tests for the current target)
- #122574 (Register LLVM handlers for bad-alloc / OOM)
- #122608 (Move check-cfg diagnostic logic into a separate file)
r? `@ghost`
`@rustbot` modify labels: rollup
Move check-cfg diagnostic logic into a separate file
as well as adding some triagebot mentions (for me) for check-cfg related files.
``@rustbot`` label +F-check-cfg
Register LLVM handlers for bad-alloc / OOM
LLVM's default bad-alloc handler may throw if exceptions are enabled,
and `operator new` isn't hooked at all by default. Now we register our
own handler that prints a message similar to fatal errors, then aborts.
We also call the function that registers the C++ `std::new_handler`.
Fixes#121305
Cc llvm/llvm-project#85281
r? ``@nikic``
mir-opt: always run tests for the current target
Currently, `./x.py test tests/mir-opt` runs only the tests for the current target, and `./x.py test tests/mir-opt --bless` runs tests for a representative set of targets. That representative set does not include the current target however, which means `--bless` can succeed when tests fail without it. This PR ensures we run the current target always.
Fixes https://github.com/rust-lang/rust/issues/122292
cc ``@RalfJung``
