Convert for each range into while loop.
```rust
fn foo() {
$0for i in 3..7 {
foo(i);
}
}
```
->
```rust
fn foo() {
let mut i = 3;
while i < 7 {
foo(i);
i += 1;
}
}
```
When completing some expressions, it is almost always expected to have a non unit value
- ArrayExpr
- ParenExpr
- BreakExpr
- ReturnExpr
- PrefixExpr
- FormatArgsArg
- RecordExprField
- BinExpr (rhs only)
- IndexExpr (inside index only)
Example
---
```rust
fn main() {
return $0;
}
```
**Before this PR**
```rust
fn main() {
return if $1 {
$0
};
}
```
**After this PR**
```rust
fn main() {
return if $1 {
$2
} else {
$0
};
}
```
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#146573 (Constify Range functions)
- rust-lang/rust#146699 (Add `is_ascii` function optimized for LoongArch64 for [u8])
- rust-lang/rust#148026 (std: don't leak the thread closure if destroying the thread attributes fails)
- rust-lang/rust#148135 (Ignore unix socket related tests for VxWorks)
- rust-lang/rust#148211 (clippy fixes and code simplification)
- rust-lang/rust#148395 (Generalize branch references)
- rust-lang/rust#148405 (Fix suggestion when there were a colon already in generics)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix suggestion when there were a colon already in generics
Finally found time to fix https://github.com/rust-lang/rust/issues/144215
I don't feel like this `colon_flag` is perfect solution and that it can be refactored, but I'd say that this is pretty good as it, I was tried to refactor this a little, but the thing is the scope where `param.colon_span` lives is very limited, so there is not much time to check was there colon or not, I tried to rewrite this into more functional style to address this, but it becomes way more unreadable than this one or even less performant, maybe some comments could push readability of this fix further, maybe a comment for enum or `colon_flag`?
Generalize branch references
It should be safe to merge this before the rename, and I'd like to do that, so we can test if beta/stable PRs work.
r? ``@marcoieni``
Ignore unix socket related tests for VxWorks
Unix Sockets are not implemented in VxWorks, and therefore, ignore testcases related to UnixDatagram, UnixListener and UnixStream.
std: don't leak the thread closure if destroying the thread attributes fails
The comment about double-free is wrong – we can safely drop both the thread attributes and the thread closure. Here, I've used `DropGuard` for the attributes and moved the `Box::into_raw` to just before the `pthread_create`.