Remove chalk support from the compiler
Removes chalk (`-Ztrait-solver=chalk`) from the compiler and prunes any dead code resulting from this, mainly:
* Remove the chalk compatibility layer in `compiler/rustc_traits/src/chalk`
* Remove the chalk flag `-Ztrait-solver=chalk` and its `TraitEngine` implementation
* Remove `TypeWellFormedFromEnv` (and its many `bug!()` match arms)
* Remove the chalk migration mode from compiletest
* Remove the `chalkify` UI tests (do we want to keep any of these, but migrate them to `-Ztrait-solver=next`??)
Fulfills rust-lang/types-team#93.
r? `@jackh726`
Upgrade to indexmap 2.0.0
The new version was already added to the tree as an indirect dependency
in #113046, but now our direct dependents are using it too.
Make RPITITs assume/require their parent method's predicates
Removes a FIXME from the `param_env` query where we were manually adding the parent function's predicates to the RPITIT's assumptions.
r? `@spastorino`
lint/ctypes: ext. abi fn-ptr in internal abi fn
Fixes#94223.
- In the improper ctypes lint, instead of skipping functions with internal ABIs, check that the signature doesn't contain any fn-ptr types with external ABIs that aren't FFI-safe.
- When computing the ABI for fn-ptr types, remove an `unwrap` that assumed FFI-safe types in foreign fn-ptr types.
- I'm not certain that this is the correct approach.
Implement selection via new trait solver
Implements selection via the new solver by calling into `assemble_and_evaluate_candidates`, doing a very light-weight "winnow" to choose one candidate over the others, and then re-confirming that candidate outside of the `EvalCtxt` in order to compute the information necessary for the `ImplSource`.
This selection routine is best effort -- if it receives an ambiguous response from the `EvalCtxt`, then it may return ambiguity if the work to re-confirm the goal is not "easy" -- right now, that means everything except for object and impl goals. Since we don't want to reimplement all of the work of the `compute_builtin_*` methods in the solver internals, we bail out if we encounter ambiguity more often than the old solver. This should only barely affect [method selection](f798ada7ba/compiler/rustc_hir_typeck/src/method/probe.rs (L1447)) and not codegen. It can be made more precise later if needed.
r? `@lcnr`
Revert "Suggest `x build library` for a custom toolchain that fails to load `core`"
This reverts commit b913f5593d.
CI builds with profile=nightly, causing different test output.
Making the output depend on the release channel was not a great idea and we have to be more careful with this.
I did not realize that the change could have such effects on test output but it's kinda obvious with hindsight >.<.
This reverts commit b913f5593d.
CI builds with profile=nightly, causing different test output.
Making the output depend on the release channel was not a great idea.
Extend previous checks for external ABI fn-ptrs to use in internal
statics, constants, type aliases and algebraic data types.
Signed-off-by: David Wood <david.wood@huawei.com>
Extend previous commit's support for checking for external fn-ptrs in
internal fn types to report errors for multiple found fn-ptrs.
Signed-off-by: David Wood <david.wood@huawei.com>
Instead of skipping functions with internal ABIs, check that the
signature doesn't contain any fn-ptr types with external ABIs that
aren't FFI-safe.
Signed-off-by: David Wood <david.wood@huawei.com>
implement deep normalization via the new solver
together with #112869 this should remove all uses of the old solver with `-Ztrait-solver=next`.
see https://hackmd.io/V0qsUB_fTxexfQO_pcOcrg for a description of this PR. Will move that doc to the `rustc-dev-guide` after merging this.
r? `@compiler-errors`
Rollup of 3 pull requests
Successful merges:
- #113253 (Fixed documentation of from<CString> for Rc<CStr>: Arc -> Rc)
- #113258 (Migrate GUI colors test to original CSS color format)
- #113259 (Suggest `x build library` for a custom toolchain that fails to load `core`)
r? `@ghost`
`@rustbot` modify labels: rollup
Rewrite `UnDerefer`
Currently, `UnDerefer` is used by drop elaboration to undo the effects of the `Derefer` pass. However, it just recreates the original places with derefs in the middle of the projection. Because `ProjectionElem::Deref` is intended to be removed completely in the future, this will not work forever.
This PR introduces a `deref_chain` method that returns the places behind `DerefTemp` locals in a place and rewrites the move path code to use this. In the process, `UnDerefer` was merged into `MovePathLookup`. Now that move paths use the same places as in the MIR, the other uses of `UnDerefer` no longer require it.
See #98145
cc `@ouz-a`
r? `@oli-obk`
