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 😆
Rollup of 7 pull requests
Successful merges:
- #137759 (Add `std::os::unix::process::CommandExt::chroot` to safely chroot a child process)
- #140994 (replace `cc_detect::cc2ar` with `cc::try_get_archiver`)
- #141213 (Suggest use "{}", self.x instead of {self.x} when resolve x as field of `self`)
- #141283 (Allow `x perf` to find rustc.exe on Windows)
- #141284 (Allow trailing comma after argument in query definition)
- #141317 (typeck: catch `continue`s pointing to blocks)
- #141318 (Avoid creating an empty identifer in `Symbol::to_ident_string`.)
r? `@ghost`
`@rustbot` modify labels: rollup
