Skip to content

do not emit OpaqueCast projections with -Znext-solver #139902

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 17, 2025

Conversation

lcnr
Copy link
Contributor

@lcnr lcnr commented Apr 16, 2025

We normalize opaque types in their defining scope if the new solver is enabled. This means projections do not contain any 'revealable' opaque types we need to worry about. We either have a type which has been normalized by writeback or we need to normalize it anyways.

r? @compiler-errors @oli-obk

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 16, 2025
@rustbot
Copy link
Collaborator

rustbot commented Apr 16, 2025

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

This PR changes MIR

cc @oli-obk, @RalfJung, @JakobDegen, @davidtwco, @vakaras

Some changes occurred in match lowering

cc @Nadrieril

// hidden types, so we don't need these projections anymore.
//
// Performance optimization: don't reintern if there is no `OpaqueCast` to remove.
if place.projection.iter().any(|elem| matches!(elem, ProjectionElem::OpaqueCast(_))) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this also affects the old solver as we now continue to super_visit even if there are no opaque casts involved.

I think this is more correct as we want to normalize types and consts regardless of whether a projection contained an opaque.

@oli-obk
Copy link
Contributor

oli-obk commented Apr 16, 2025

Do we have tests that actually excercise this in the old solver where the tests are also run with the new solver?

@lcnr lcnr force-pushed the no-opaque-cast-projection branch from 5200c77 to 111cabc Compare April 17, 2025 10:36
@lcnr
Copy link
Contributor Author

lcnr commented Apr 17, 2025

enabled two tests which started to fail with the old solver

@bors r=oli-obk rollup

@bors
Copy link
Collaborator

bors commented Apr 17, 2025

📌 Commit 111cabc has been approved by oli-obk

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 17, 2025
@lcnr lcnr force-pushed the no-opaque-cast-projection branch from 111cabc to c85b5fc Compare April 17, 2025 10:41
@lcnr
Copy link
Contributor Author

lcnr commented Apr 17, 2025

@bors r=oli-obk rollup

@bors
Copy link
Collaborator

bors commented Apr 17, 2025

📌 Commit c85b5fc has been approved by oli-obk

It is now in the queue for this repository.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Apr 17, 2025
…oli-obk

do not emit `OpaqueCast` projections with `-Znext-solver`

We normalize opaque types in their defining scope if the new solver is enabled. This means projections do not contain any 'revealable' opaque types we need to worry about. We either have a type which has been normalized by writeback or we need to normalize it anyways.

r? `@compiler-errors` `@oli-obk`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Apr 17, 2025
…oli-obk

do not emit `OpaqueCast` projections with `-Znext-solver`

We normalize opaque types in their defining scope if the new solver is enabled. This means projections do not contain any 'revealable' opaque types we need to worry about. We either have a type which has been normalized by writeback or we need to normalize it anyways.

r? ``@compiler-errors`` ``@oli-obk``
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 17, 2025
…iaskrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#139774 (Fix replacing supertrait aliases in `ReplaceProjectionWith`)
 - rust-lang#139850 (Hide unstable print kinds within emit_unknown_print_request_help in stable channel)
 - rust-lang#139870 (add retries to remove and create dir all)
 - rust-lang#139902 (do not emit `OpaqueCast` projections with `-Znext-solver`)
 - rust-lang#139931 (bootstrap: enable zlib for LLVM for Windows GNU)
 - rust-lang#139935 (Upgrade to `rustc-rayon-core` 0.5.1)
 - rust-lang#139943 (rustdoc: Support inlined cross-crate re-exported trait aliases)
 - rust-lang#139961 (Two `rustc_const_eval` cleanups)
 - rust-lang#139962 (opt-dist: add a flag for running tests)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 67e2358 into rust-lang:master Apr 17, 2025
6 checks passed
@rustbot rustbot added this to the 1.88.0 milestone Apr 17, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Apr 17, 2025
Rollup merge of rust-lang#139902 - lcnr:no-opaque-cast-projection, r=oli-obk

do not emit `OpaqueCast` projections with `-Znext-solver`

We normalize opaque types in their defining scope if the new solver is enabled. This means projections do not contain any 'revealable' opaque types we need to worry about. We either have a type which has been normalized by writeback or we need to normalize it anyways.

r? ```@compiler-errors``` ```@oli-obk```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants