Consider polarity in new solver by compiler-errors · Pull Request #110671 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation9 Commits2 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
It's kinda ugly to have a polarity check in all of the builtin impls -- I guess I could consider the polarity at the top of assemble-builtin but that would require adding a polarity fn to GoalKind...
🤷 putting this up just so i dont forget, since it's needed to bootstrap core during coherence (this alone does not allow core to bootstrap though, additional work is needed!)
r? @lcnr
Some changes occurred to the core trait solver
cc @rust-lang/initiative-trait-system-refactor
Contributor
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add tests here (not even specific to the new solver) asserting that T: !Trait does not hold when there's a builtin + or param env candidate for T: Trait?
after that r=me
I am a bit unhappy with checking goal.predicate.polarity explicitly in all consider X methods 🤔 it is probably cleaner to add it to GoalKind and check it in the caller. THink the current state is fine but it may be worth experimenting with this here.
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
There's no parser support for negative impl polarity predicates in where clauses, so I have no idea how to test that T: !Trait holds 😅
The best I can do is provide the minimized test failure I have that uses #![feature(with_negative_coherence)] and then new solver.
This comment has been minimized.
Contributor
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
forgot that we currently don't support negative where bounds, i think we may want to support them. it would help with #85099. doesn't matter for this PR though
This comment has been minimized.
Added an explanation
@bors r=lcnr rollup (new solver)
📌 Commit bb2cb89 has been approved by lcnr
It is now in the queue for this repository.
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
Consider polarity in new solver
It's kinda ugly to have a polarity check in all of the builtin impls -- I guess I could consider the polarity at the top of assemble-builtin but that would require adding a polarity fn to GoalKind...
:shrug: putting this up just so i dont forget, since it's needed to bootstrap core during coherence (this alone does not allow core to bootstrap though, additional work is needed!)
r? @lcnr
bors added a commit to rust-lang-ci/rust that referenced this pull request
…iaskrgr
Rollup of 6 pull requests
Successful merges:
- rust-lang#110556 (Switch to
EarlyBinderforexplicit_item_bounds) - rust-lang#110615 (Add
impl_tag!macro to implementTagfor tagged pointer easily) - rust-lang#110649 (Fix no_global_oom_handling build)
- rust-lang#110671 (Consider polarity in new solver)
- rust-lang#110783 (Fix ICE on --print=... i/o errors)
- rust-lang#110796 (Updating Wake example to use new 'pin!' macro)
Failed merges:
r? @ghost
@rustbot modify labels: rollup
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request
…=oli-obk
Implement negative bounds for internal testing purposes
Implements partial support the ! negative polarity on trait bounds. This is incomplete, but should allow us to at least be able to play with the feature.
Not even gonna consider them as a public-facing feature, but I'm implementing them because would've been nice to have in UI tests, for example in rust-lang#110671.
Labels
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Relevant to the compiler team, which will review and decide on the PR/issue.
The Rustc Trait System Refactor Initiative (-Znext-solver)