lower bodies' params to thir before the body's value
Two motivations for this:
- Lowering params first means errors from lowering the params are emitted before errors from lowering the body's expression. This comes up in [tests/ui/associated-consts/associated-const-type-parameter-pattern.stderr](https://github.com/rust-lang/rust/compare/master...dianne:rust:thir-lower-params-before-body-expr?expand=1#diff-acac6ea10e991af0da91633e08b2739f9f9ca0c8f826401b6ba829914d0806f2), where both the params and expression encounter errors in translating consts to patterns. This change puts the errors in the order they appear in the source file.
- Guard patterns (#129967) contain expressions, so lowering params containing guard patterns may add more expressions to the THIR. However, there's a check for `-Zunpretty=thir-tree` that the final expression in the THIR corresponds to its value [(link)](c43786c9b7/compiler/rustc_mir_build/src/builder/mod.rs (L453-L455)); lowering params last would break this. As an alternative way to get guard patterns to work, I think the pretty-printer could use the expression returned by `thir_body` and the check could be removed or changed (#141357).
incorrectly prefer builtin `dyn` impls :3
This makes #57893 slightly more exploitable with the new solver. It's still strictly better than the old solver and the underlying unsoundness persists in the new one even without this preference.
Properly fixing #57893 is something we've been looking at more deeply recently and discussed at the [Types Meetup during the All-Hands](https://hackmd.io/rz-4ghMzTb2wXOkdLKHaHw#Dyn-traits). Whatever approach we'll end up deciding on will likely require a fairly long transition period and some significant further design work. This should not block `-Znext-solver`.
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/183
r? `@compiler-errors` cc `@rust-lang/types`
limit impls of `VaArgSafe` to just types that are actually safe
tracking issue: https://github.com/rust-lang/rust/issues/44930
Retrieving 8- or 16-bit integer arguments from a `VaList` is not safe, because such types are subject to upcasting. See https://github.com/rust-lang/rust/issues/61275#issuecomment-2193942535 for more detail.
This PR also makes the instances of `VaArgSafe` visible in the documentation, and uses a private sealed trait to make sure users cannot create additional impls of `VaArgSafe`, which would almost certainly cause UB.
r? `@workingjubilee`
Rollup of 7 pull requests
Successful merges:
- #141267 (only resolve top-level guard patterns' guards once)
- #141280 (Use Docker cache from the current repository)
- #141296 (Async drop fix for 'broken mir, place has deref as later projection')
- #141328 (When AsyncDrop impl is empty, sync drop generated in elaborator)
- #141332 (Do not eagerly fold consts in `normalize_param_env_or_error` if new solver)
- #141333 (Use `DeepRejectCtxt` in `assemble_inherent_candidates_from_param`)
- #141334 (eagerly check nested obligations when coercing fndefs)
r? `@ghost`
`@rustbot` modify labels: rollup
Do not eagerly fold consts in `normalize_param_env_or_error` if new solver
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/213
Given:
```
trait Trait: Deref<Target = [u8; { 1 + 1 }]> {}
```
when elaborating param env for `Trait`, we have `Self: Trait`, `Self: Deref<Target = [u8; {anon const}]>`.
Before this PR, we would fold the anon consts away *before* elaborating. However, we end up getting another *un-folded* copy of the anon const from elaborating `Self: Trait`. This leads to normalization ambiguity.
r? lcnr
Use Docker cache from the current repository
This is needed to make the cache work after moving CI from the `rust-lang-ci` org to `rust-lang`. Shouldn't be merged until we actually move bors.
Context: https://github.com/rust-lang/infra-team/issues/188
r? `@marcoieni`
only resolve top-level guard patterns' guards once
We resolve guard patterns' guards in `resolve_pattern_inner`, so to avoid resolving them multiple times, we must avoid doing so earlier. To accomplish this, `LateResolutionVisitor::visit_pat` contains a case for guard patterns that avoids visiting their guards while walking patterns.
This PR fixes#141265, which was due to `visit::walk_pat` being used instead; this meant guards at the top level of a pattern would be visited twice. e.g. it would ICE on `for x if x in [] {}`, but not `for (x if x) in [] {}`. `visit_pat` was already used for the guard pattern in the second example, on account of the top-level pattern being parens.
8 and 16-bit integers are subject to upcasting in C, and hence are not reliably safe. users should perform their own casting and deal with the consequences
Match on lang item kind instead of using an if/else chain
Similar to how the new solver does this. Just noticed while I was adding a new entry to the chain 😆
