Suggest `;` or assignment to drop borrows in tail exprs
Address the diagnostics part of #70844.
```
error[E0597]: `counter` does not live long enough
--> $DIR/issue-54556-niconii.rs:22:20
|
LL | if let Ok(_) = counter.lock() { }
| ^^^^^^^-------
| |
| borrowed value does not live long enough
| a temporary with access to the borrow is created here ...
...
LL | }
| -
| |
| `counter` dropped here while still borrowed
| ... and the borrow might be used here, when that temporary is dropped and runs the destructor for type `std::result::Result<MutexGuard<'_>, ()>`
|
help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped
|
LL | if let Ok(_) = counter.lock() { };
| ^
```
Const-prop bugfix: only add propagation inside own block for user variables
A testing spinoff of #71298. This one only adds the const-prop for locals that are user variables.
Address the diagnostics part of #70844.
```
error[E0597]: `counter` does not live long enough
--> $DIR/issue-54556-niconii.rs:22:20
|
LL | if let Ok(_) = counter.lock() { }
| ^^^^^^^-------
| |
| borrowed value does not live long enough
| a temporary with access to the borrow is created here ...
...
LL | }
| -
| |
| `counter` dropped here while still borrowed
| ... and the borrow might be used here, when that temporary is dropped and runs the destructor for type `std::result::Result<MutexGuard<'_>, ()>`
|
help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped
|
LL | if let Ok(_) = counter.lock() { };
| ^
```
Moving more build-pass tests to check-pass
One or two tests became build-pass without the FIXME because they really
needed build-pass (were failing without it).
Helps with #62277
---
<!-- Reviewable:start -->
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/rust-lang/rust/71340)
<!-- Reviewable:end -->
Rollup of 5 pull requests
Successful merges:
- #71311 (On `FnDef` type annotation suggestion, use fn-pointer output)
- #71488 (normalize field projection ty to fix broken MIR issue)
- #71489 (Fix off by one in treat err as bug)
- #71585 (remove obsolete comment)
- #71634 (Revert #71372 ("Fix #! (shebang) stripping account space issue").)
Failed merges:
r? @ghost
smoke-test for async fn with mir-opt-level=0
MIR opt levels heavily influence which MIR transformations run, and we barely test non-default opt levels. I am particularly worried about `async fn` lowering and how it might (not) work when the set of preceding MIR passes changes -- see https://github.com/rust-lang/rust/pull/70073.
This adds some basic smoke testing, where at least a few `async fn` `run-pass` test are ensured to also work with mir-opt-level=0.
If it is possible to convert an integer type into another using
`into`, don't suggest `try_into`. This commit changes the suggested
method to convert from one integer type to another for the following
cases:
- u{n} -> i{m} where n < m
- u8 -> isize
- i{n} -> isize where n <= 16
- u{n} -> usize where n <= 16
Add a function to turn Box<T> into Box<[T]>
Hi,
I think this is very useful, as currently it's not possible in safe rust to do this without re-allocating.
an alternative implementation of the same function can be:
```rust
pub fn into_boxed_slice<T>(boxed: Box<T>) -> Box<[T]> {
unsafe {
let slice = slice::from_raw_parts_mut(Box::into_raw(boxed), 1);
Box::from_raw(slice)
}
}
```
The only thing that makes me a little uncomfortable is this line :
> The alignment of array types is greater or equal to the alignment of its element type
from https://rust-lang.github.io/unsafe-code-guidelines/layout/arrays-and-slices.html
But then I see:
> The alignment of &T, &mut T, *const T and *mut T are the same, and are at least the word size.
> The alignment of &[T] is the word size.
from https://rust-lang.github.io/unsafe-code-guidelines/layout/pointers.html#representation
So I do believe this is valid(FWIW it also passes in miri https://play.rust-lang.org/?gist=c002b99364ee6b29862aeb3565a91c19)
[breaking change] Disallow statics initializing themselves
fixes#71078
Self-initialization is unsound because it breaks privacy assumptions that unsafe code can make. In
```rust
pub mod foo {
#[derive(Debug, Copy, Clone)]
pub struct Foo {
x: (),
}
}
pub static FOO: foo::Foo = FOO;
```
unsafe could could expect that ony functions inside the `foo` module were able to create a value of type `Foo`.
Add all remaining `DefKind`s.
r? @eddyb or @Centril
~~I'm not sure if this is what you were thinking of. There are also a few places where I'm not sure what the correct choice is because I don't fully understand the meaning of some variants.~~
~~In general, it feels a bit odd to add some of these as `DefKind`s (e.g. `Arm`) because they don't feel like definitions. Are there things that it makes sense not to add?~~
Fix span of while (let) expressions after lowering
Credit goes to @alex-700 who found this while trying to fix a suggestion in Clippy.
While `if`, `try`, `for` and `await` expressions get the span of the original expression when desugared, `while` loops got the span of the scrutinee, which lead to weird code, when building the suggestion, that randomly worked: https://github.com/rust-lang/rust-clippy/pull/5511/files#diff-df4e9d2bf840a5f2e3b580bef73da3bcR106-R108
I'm wondering, if `DesugaringKind` should get a variant `WhileLoop` and instead of using the span of the `ast::ExprKind::While` expr directly, a new span with `self.mark_span_with_reason` should be used, like it is done with `for` loops.
There was some fallout, but I think that is acceptable. If not, I need some help to find out where this can be fixed.
Only run dataflow for const qualification if type-based check would fail
This is the optimization discussed in https://github.com/rust-lang/rust/issues/49146#issuecomment-614012476. We wait for `Qualif::in_any_value_of_ty` to return `true` before running dataflow. For bodies that deal mostly with primitive types, this will avoid running dataflow at all during const qualification.
This also removes the `BitSet` used to cache `in_any_value_of_ty` for each local, which was only necessary for an old version of #64470 that also handled promotability.
