Handle opaques in the new solver (take 2?)
Implement a new strategy for handling opaques in the new solver.
First, queries now carry both their defining anchor and the opaques that were defined in the inference context at the time of canonicalization. These are both used to pre-populate the inference context used by the canonical query.
Second, use the normalizes-to goal to handle opaque types in the new solver. This means that opaques are handled like projection aliases, but with their own rules:
* Can only define opaques if they're "defining uses" (i.e. have unique params in all their substs).
* Can only define opaques that are from the anchor.
* Opaque type definitions are modulo regions. So that means `Opaque<'?0r> = HiddenTy1` and `Opaque<?'1r> = HiddenTy2` equate `HiddenTy1` and `HiddenTy2` instead of defining them as different opaque type keys.
Rollup of 4 pull requests
Successful merges:
- #95198 (Add slice::{split_,}{first,last}_chunk{,_mut})
- #109899 (Use apple-m1 as target CPU for aarch64-apple-darwin.)
- #111624 (Emit diagnostic for privately uninhabited uncovered witnesses.)
- #111875 (Don't leak the function that is called on drop)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't leak the function that is called on drop
It probably wasn't causing problems anyway, but still, a `// this leaks, please don't pass anything that owns memory` is not sustainable.
I could implement a version which does not require `Option`, but it would require `unsafe`, at which point it's probably not worth it.
Use apple-m1 as target CPU for aarch64-apple-darwin.
This updates the target CPU for the `aarch64-apple-darwin` target to `apple-m1`, which is the first generation of CPUs with this target anyway.
This wasn't able to be done before because of the minimum supported version of LLVM being 12, now that it was updated to 13 (in fact we are already at 14), this is available.
See previous update: https://github.com/rust-lang/rust/pull/90478.
See LLVM update: https://github.com/rust-lang/rust/pull/100460.
Rollup of 5 pull requests
Successful merges:
- #111741 (Use `ObligationCtxt` in custom type ops)
- #111840 (Expose more information in `get_body_with_borrowck_facts`)
- #111876 (Roll compiler_builtins to 0.1.92)
- #111912 (Use `Option::is_some_and` and `Result::is_ok_and` in the compiler )
- #111915 (libtest: Improve error when missing `-Zunstable-options`)
r? `@ghost`
`@rustbot` modify labels: rollup
Use `Option::is_some_and` and `Result::is_ok_and` in the compiler
`.is_some_and(..)`/`.is_ok_and(..)` replace `.map_or(false, ..)` and `.map(..).unwrap_or(false)`, making the code more readable.
This PR is a sibling of https://github.com/rust-lang/rust/pull/111873#issuecomment-1561316515
Expose more information in `get_body_with_borrowck_facts`
Verification tools for Rust such as, for example, Creusot or Prusti would benefit from having access to more information computed by the borrow checker.
As a first step in that direction, #86977 added the `get_body_with_borrowck_facts` API, allowing compiler consumers to obtain a `mir::Body` with accompanying borrow checker information.
At RustVerify 2023, multiple people working on verification tools expressed their need for a more comprehensive API.
While eventually borrow information could be part of Stable MIR, in the meantime, this PR proposes a more limited approach, extending the existing `get_body_with_borrowck_facts` API.
In summary, we propose the following changes:
- Permit obtaining the borrow-checked body without necessarily running Polonius
- Return the `BorrowSet` and the `RegionInferenceContext` in `BodyWithBorrowckFacts`
- Provide a way to compute the `borrows_out_of_scope_at_location` map
- Make some helper methods public
This is similar to #108328 but smaller in scope.
`@smoelius` Do you think these changes would also be sufficient for your needs?
r? `@oli-obk`
cc `@JonasAlaif`
Use `ObligationCtxt` in custom type ops
We already make one when evaluating the `CustomTypeOp`, so it's simpler to just pass it to the user. Removes a redundant `ObligationCtxt::new_in_snapshot` usage and simplifies some other code.
This makes several refactorings related to opaque types in the new solver simpler, but those are not included in this PR.
Rollup of 6 pull requests
Successful merges:
- #111121 (Work around `rust-analyzer` false-positive type errors)
- #111759 (Leverage the interval property to precompute borrow kill points.)
- #111841 (Run AST validation on match guards correctly)
- #111862 (Split out opaque collection from from `type_of`)
- #111863 (Don't skip mir typeck if body has errors)
- #111903 (Migrate GUI colors test to original CSS color format)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't skip mir typeck if body has errors
Comment says:
```
// if verifier failed, don't do further checks to avoid ICEs
```
But there are no ICEs to be found. The comment is quite old, so perhaps something fixed it... maybe because the MIR typechecker is delaying span bugs rather than panicking via eager bugs? IDK
I'm generally inclined to fix the ICEs themselves that were to arise from this, rather than just totally skipping large parts of the compiler that have impacts on downstream logic (namely, our opaque type results are affected). Anyways, this happens on the error path, so it shouldn't really matter.
Fixes this hack: https://github.com/rust-lang/rust/pull/111853/files#r1201501540
Work around `rust-analyzer` false-positive type errors
rust-analyzer incorrectly reports two type errors in `debug.rs`:
> expected &dyn Display, found &i32
> expected &dyn Display, found &i32
This is due to a known bug in r-a: (https://github.com/rust-lang/rust-analyzer/issues/11847).
In these particular cases, changing `&0` to `&0i32` seems to be enough to avoid the bug.
Preprocess and cache dominator tree
Preprocessing dominators has a very strong effect for https://github.com/rust-lang/rust/pull/111344.
That pass checks that assignments dominate their uses repeatedly. Using the unprocessed dominator tree caused a quadratic runtime (number of bbs x depth of the dominator tree).
This PR also caches the dominator tree and the pre-processed dominators in the MIR cfg cache.
Rebase of https://github.com/rust-lang/rust/pull/107157
cc `@tmiasko`
Don't assume that `-Bdynamic` is the default linker mode
In particular this is false when passing `-static` or `-static-pie` to the linker, which changes the default to `-Bstatic`. This PR ensures we explicitly initialize the correct mode when we first need it.
Always require closure parameters to be `Sized`
The `rust-call` ABI isn't compatible with `#![feature(unsized_fn_params)]`, so trying to use that feature with closures leads to an ICE (#67981). This turns that ICE into a type-check error.
`@rustbot` label A-closures F-unsized_fn_params
CFI: Fix encode_region: unexpected ReEarlyBound(0, 'a)
Fixes#111515 and complements #106547 by adding support for encoding early bound regions and also excluding projections when transforming trait objects' traits into their identities before emitting type checks.
fix(resolve): not defined `extern crate shadow_name`
Fixes https://github.com/rust-lang/rust/issues/109148
## Why does #109148 panic?
When resolving `use std::xx` it enters `visit_scopes` from `early_resolve_ident_in_lexical_scope`, and iters twice during the loop:
|iter| `scope` | `break_result` | result |
|-|-|-|-|
| 0 | `Module` pointed to root | binding pointed to `Undetermined`, so result is `None` | scope changed to `ExternPrelude` |
| 1 | `ExternPrelude` | binding pointed to `std` | - |
Then, the result of `maybe_resolve_path` is `Module(std)`, so `import.imported_module.set` is executed.
Finally, during the `finalize_import` of `use std::xx`, `resolve_path` returns `NonModule` because `Binding(Ident(std), Module(root)`'s binding points to `extern crate blah as std`, which causes the assertion to fail at `assert!(import.imported_module.get().is_none());`.
## Investigation
The question is why `#[a] extern crate blah as std` is not defined as a binding of `std::xxx`, which causes the iteration twice during `visit_scopes` when resolving `std::xxx`. Ideally, the value of `break_result.is_some()` should have been valid in the first iteration.
After debugging, I found that because `#[a] extern crate blah as std` had been dummied by `placeholder` during `collect_invocations`, so it had lost its attrs, span, etc..., so it will not be defined. However, `expand_invoc` added them back, then the next `build_reduced_graph`, `#[a] extern crate blah as std` would have been defined, so it makes the result of `resolved_path` unexpected, and the program panics.
## Try to solve
I think there has two-way to solve this issue:
- Expand invocations before the first `resolve_imports` during `fully_expand_fragment`. However, I do not think this is a good idea because it would mess up the current design.
- As my PR described: do not define to `extern crate blah as std` during the second `build_reduced_graph`, which is very easy and more reasonable.
r? `@petrochenkov`
Pretty-print inherent projections correctly
Previously, we were trying to pretty-print inherent projections with `Printer::print_def_path` which is incorrect since
it expects the substitutions to be of a certain format (parents substs followed by own substs) which doesn't hold for
inherent projections (self type subst followed by own substs).
Now we print inherent projections manually.
Fixes#111390.
Fixes#111397.
Lacking tests! Is there a test suite / compiletest flags for the pretty-printer? In most if not all cases,
inherent projections are normalized away before they get the chance to appear in diagnostics.
If I were to create regression tests for linked issues, they would need to be `mir-opt` tests to exercise
`-Zdump-mir=all` (right?) which doesn't feel quite adequate to me.
`@rustbot` label F-inherent_associated_types
The `rust-call` ABI isn't compatible with
`#![feature(unsized_fn_params)]`, so trying to use that feature with
closures leads to an ICE (#67981). This turns that ICE into a
type-check error.
Fixes#111515 and complements #106547 by adding support for encoding
early bound regions and also excluding projections when transforming
trait objects' traits into their identities before emitting type checks.
Fix some issues with folded AArch64 features
In #91608 the `fp` feature was removed for AArch64 and folded into the `neon` feature, however disabling the `neon` feature doesn't actually disable the `fp` feature. If my understanding on that thread is correct it should do.
While doing this, I also noticed that disabling some features would disable features that it shouldn't. For instance enabling `sve` will enable `neon`, however, when disabling `sve` it would then also disable `neon`, I wouldn't expect disabling `sve` to also disable `neon`.
cc `@workingjubilee`
