Make well-formedness predicates no longer coinductive
This PR makes well-formedness no longer coinductive. It was made coinductive in https://github.com/rust-lang/rust/pull/98542, but AFAICT this was only to fix UI tests since we stopped lowering `where Ty:` to an empty-region outlives predicate but to a WF predicate instead.
Arguably it should lower to something completely different, something like a "type mentioned no-op predicate", but well-formedness serves this purpose fine today, and since no code (according to crater) relies on this coinductive behavior, we'd like to avoid having to emulate it in the new solver.
Fixes#123456 (I didn't want to add a test since it seems low-value to have a ICE test for a fuzzer minimization that is basically garbage code.)
Fixes#109764 (not sure if this behavior is emulatable w/o coinductive WF?)
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/169
r? lcnr
trait_sel: deep reject `match_normalize_trait_ref`
Spotted during an in-person review of #137944 at RustWeek: `match_normalize_trait_ref` could be using `DeepRejectCtxt` to exit early as an optimisation for projection candidates, like is done with param candidates.
r? `@lcnr`
cc `@oli-obk`
Use the new solver in the `impossible_predicates`
The old solver is unsound for many reasons. One of which was weaponized by `@lcnr` in #140212, where the old solver was incompletely considering a dyn vtable method to be impossible and replacing its vtable entry with a null value. This null function could be called post-mono.
The new solver is expected to be less incomplete due to its correct handling of higher-ranked aliases in relate. This PR switches the `impossible_predicates` query to use the new solver, which patches this UB.
r? lcnr
Stage0 bootstrap update
This PR [follows the release process](https://forge.rust-lang.org/release/process.html#master-bootstrap-update-tuesday) to update the stage0 compiler.
The only thing of note is 58651d1b31, which was flagged by clippy as a correctness fix. I think allowing that lint in our case makes sense, but it's worth to have a second pair of eyes on it.
r? `@Mark-Simulacrum`
Spotted during an in-person review of unrelated changes,
`match_normalize_trait_ref` could be using `DeepRejectCtxt` to exit early
as an optimisation for prejection candidates, like is done in param
candidates.
Revert "Rollup merge of #129343 - estebank:time-version, r=jieyouxu"
This reverts commit 26f75a65d7, reversing
changes made to 2572e0e8c9.
Imports are modified to fix merge conflicts and remove unused ones.
detect additional uses of opaques after writeback
Based on #140607. It's a lot harder to encounter in practice than I though 😅😁 I've still added it with the expectation that somebody will encounter it at some point.
Also modifies the `EvalCtxt` to use the same impl to detect newly added opaque types.
r? ``@compiler-errors``
`fn check_opaque_type_parameter_valid` defer error
Will be used in #139587 to silence opaque type errors if there are other borrowck failures. I think it can be merged separately.
r? `@compiler-errors`
Removing rustc_type_ir in the rustc_infer codebase
cc #138449
This is a second refactoring of rustc_type_ir to use rustc_middle instead, this time that's for rustc_infer
Refactor rustc_on_unimplemented's filter parser
Followup to https://github.com/rust-lang/rust/pull/139091; I plan on moving most of this code into `rustc_attr_parsing` at some point, but want to land this separately first.
I have taken care to preserve the original behavior as much as I could:
- All but one of the new error variants are replacements for the ones originally emitted by the cfg parsing machinery; so these errors are not "new".
- the `InvalidFlag` variant is new, this PR turns this (from being ignored and silently doing nothing) into an error:
```rust
#[rustc_on_unimplemented(on(something, message = "y"))]
//~^ ERROR invalid boolean flag
//~^^ NOTE expected one of `crate_local`, `direct` or `from_desugaring`, not `something`
trait InvalidFlag {}
```
This does not occur anywhere except in this test. I couldn't find a way that I liked to keep allowing this or to do nothing, erroring was the cleanest solution.
- There are a bunch of FIXME throughout this and the previous PR, I plan on addressing those in follow up prs..
Finally, this gets rid of the "longest" dependency in rustc:
Set groundwork for proper const normalization
r? lcnr
Updates a lot of our normalization/alias infrastructure to be setup to handle mgca aliases and normalization once const items are represented more like aliases than bodies. Inherent associated consts are still super busted, I didn't update the assertions that IACs the right arg setup because that winds up being somewhat involved to do *before* proper support for normalizing const aliases is implemented.
I dont *intend* for this to have any effect on stable. We continue normalizing via ctfe on stable and the codepaths in `project` for consts should only be reachable with mgca or ace.
Use select in projection lookup in `report_projection_error`
Using `for_each_relevant_impl` doesn't actually select the correct impl; we can use `select` here to actually get the correct impl with certainty. Follow-up to https://github.com/rust-lang/rust/pull/140278.
r? oli-obk
This commit does the following:
- Replaces use of rustc_type_ir by rustc_middle in rustc_infer.
- The DelayedMap type is exposed by rustc_middle so everything can be
accessed through rustc_middle in a coherent manner.
- API-layer traits, like InferCtxtLike, Interner or inherent::* must be
accessed via rustc_type_ir, not rustc_middle::ty. For this reason
these are not reexported by rustc_middle::ty.
- Replaces use of ty::Interner by rustc_type_ir::Interner in
rustc_trait_selection
Replace use of rustc_type_ir by rustc_middle
cc #138449
I want to help on this issue. I have replaced all the rustc_type_ir uses by the equivalent type in rustc_middle.
DelayedSet is also re-exposed by rustc_middle.
This commit does the following:
- Replaces use of rustc_type_ir by rustc_middle
- Removes the rustc_type_ir dependency
- The DelayedSet type is exposed by rustc_middle so everything can be
accessed through rustc_middle in a coherent manner.
Rollup of 7 pull requests
Successful merges:
- #140056 (Fix a wrong error message in 2024 edition)
- #140220 (Fix detection of main function if there are expressions around it)
- #140249 (Remove `weak` alias terminology)
- #140316 (Introduce `BoxMarker` to improve pretty-printing correctness)
- #140347 (ci: clean more disk space in codebuild)
- #140349 (ci: use aws codebuild for the `dist-x86_64-linux` job)
- #140379 (rustc-dev-guide subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove `weak` alias terminology
I find the "weak" alias terminology to be quite confusing. It implies the existence of "strong" aliases (which do not exist) and I'm not really sure what about weak aliases is "weak". I much prefer "free alias" as the term. I think it's much more obvious what it means as "free function" is a well defined term that already exists in rust.
It's also a little confusing given "weak alias" is already a term in linker/codegen spaces which are part of the compiler too. Though I'm not particularly worried about that as it's usually very obvious if you're talking about the type system or not lol. I'm also currently trying to write documentation about aliases and it's somewhat awkward/confusing to be talking about *weak* aliases, when I'm not really sure what the basis for that as the term actually *is*.
I would also be happy to just find out there's a nice meaning behind calling them "weak" aliases :-)
r? `@oli-obk`
maybe we want a types MCP to decide on a specific naming here? or maybe we think its just too late to go back on this naming decision ^^'
