Account for `for` lifetimes when constructing closure to see if dereferencing the return value would be valid.

Fix rust-lang#125634, fix rust-lang#124563.

…nkfelix

Mark assoc tys live only if the corresponding trait is live

r? ````@pnkfelix````

Deny `use<>` for RPITITs

Precise capturing `use<>` syntax is currently a no-op on RPITITs, since GATs have no variance, so all captured lifetimes are captured invariantly.

We don't currently *need* to support `use<>` on RPITITs, since `use<>` is initially intended for migrating RPIT *overcaptures* from edition 2021->2024, but since RPITITs currently capture all in-scope lifetimes, we'll never need to write `use<>` on an RPITIT.

Eventually, though, it would be desirable to support precise capturing on RPITITs, since RPITITs overcapturing by default can be annoying to some folks. But let's separate that (which will likely require some delicate types team work for adding variances to GATs and adjusting the refinement rules) from the stabilization of the feature for edition 2024.

r? oli-obk cc ``@traviscross``

Tracking:

- rust-lang#123432

not use offset when there is not ends with brace

Fixes rust-lang#126764

Do not ICE when suggesting dereferencing closure arg

Account for `for` lifetimes when constructing closure to see if dereferencing the return value would be valid.

Fix rust-lang#125634, fix rust-lang#124563.

Eliminate the distinction between PREC_POSTFIX and PREC_PAREN precedence level

I have been tangling with precedence as part of porting some pretty-printer improvements from syn back to rustc (related to parenthesization of closures, returns, and breaks by the AST pretty-printer).

As far as I have been able to tell, there is no difference between the 2 different precedence levels that rustc identifies as `PREC_POSTFIX` (field access, square bracket index, question mark, method call) and `PREC_PAREN` (loops, if, paths, literals).

There are a bunch of places that look at either `prec < PREC_POSTFIX` or `prec >= PREC_POSTFIX`. But there is nothing that needs to distinguish PREC_POSTFIX and PREC_PAREN from one another.

https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_ast/src/util/parser.rs#L236-L237

https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs#L2829

https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs#L1290

In the interest of eliminating a distinction without a difference, this PR collapses these 2 levels down to 1.

There is exactly 1 case where an expression with PREC_POSTFIX precedence needs to be parenthesized in a location that an expression with PREC_PAREN would not, and that's when the receiver of ExprKind::MethodCall is ExprKind::Field. `x.f()` means a different thing than `(x.f)()`. But this does not justify having separate precedence levels because this special case in the grammar is not governed by precedence. Field access does not have "lower precedence than" method call syntax &mdash; you can tell because if it did, then `x.f[0].f()` wouldn't be able to have its unparenthesized field access in the receiver of a method call. Because this Field/MethodCall special case is not governed by precedence, it already requires special handling and is not affected by eliminating the PREC_POSTFIX precedence level.

https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_ast_pretty/src/pprust/state/expr.rs#L217-L221

…r-errors

Don't suggest awaiting in closure patterns

Fixes rust-lang#126903.

For
```rust
async fn do_async() {}

fn main() {
    Some(do_async()).map(|()| {});
}
```
the error is now
```rust
error[E0308]: mismatched types
 --> src/main.rs:4:27
  |
4 |     Some(do_async()).map(|()| {});
  |                           ^^
  |                           |
  |                           expected future, found `()`
  |                           expected due to this
  |
  = note: expected opaque type `impl Future<Output = ()>`
               found unit type `()`
```

Ideally, if `main` were to be `async`, it should be
```rs
error[E0308]: mismatched types
 --> src/main.rs:4:27
  |
4 |     Some(do_async()).map(|()| {});
  |                           ^^
  |                           |
  |                           expected future, found `()`
  |                           expected due to this
  |
  = note: expected opaque type `impl Future<Output = ()>`
               found unit type `()`
help: consider `await`ing on the `Future`
  |
4 |     Some(do_async().await).map(|()| {});
  |                    ++++++
```
However, this would mean `FnCtx::check_pat_top` would have to be called with an `origin_expr` in `rustc_hir_typeck::check::check_fn`, and that expr would have to be somehow plumbed through `FnCtxt::check_expr_closure` and closure signature deduction. I'm willing to work on the plumbing but unsure how to start.

De-duplicate all consecutive native libs regardless of their options

Address rust-lang#126913 (comment) by no longer de-duplicating based on the "options" but by only looking at the generated link args, as to avoid consecutive libs that originated from different native-lib with different options (like `raw-dylib` on Windows) but isn't relevant for `--print=native-static-libs`.

r? ``@petrochenkov``