Skip to content

stepping into impls for normalization is unproductive#139900

Merged
bors merged 1 commit intorust-lang:masterfrom
lcnr:normalizes-to-where-bounds-unproductive
Apr 17, 2025
Merged

stepping into impls for normalization is unproductive#139900
bors merged 1 commit intorust-lang:masterfrom
lcnr:normalizes-to-where-bounds-unproductive

Conversation

@lcnr
Copy link
Copy Markdown
Contributor

@lcnr lcnr commented Apr 16, 2025

See the inline comment. This builds on the reasoning from #136824 (https://gist.github.com/lcnr/c49d887bbd34f5d05c36d1cf7a1bf5a5). Fixes rust-lang/trait-system-refactor-initiative#176.

Looking at the end of the gist:

The only ways to project out of a constructor are the following:

  • accessing an associated item, either its type or its item bounds
  • accessing super predicates

Detecting cases where we accessing the type of an associated item is easy, it's simply when we normalize. I don't yet know how to detect whether we step out of an impl by accessing item bounds. Once we also detect these cases we should be able to soundly support arbitrary coinductive traits. Luckily this does not matter for this PR :>

r? @compiler-errors cc @nikomatsakis

Loading
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. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

sqlparser regression: normalizes-to impl-where clauses are nonproductive

4 participants