-
Notifications
You must be signed in to change notification settings - Fork 13.3k
return NoSolution
for default assoc items
#111994
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
Conversation
Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
@@ -0,0 +1,26 @@ | |||
// check-pass |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
want a second test:
normalizes-to
is NoSolution
if there is no specializing impl, projection remains rigid
normalizes-to
chooses the specializing impl over the default impl where applicable
SolverMode::Normal => return Err(NoSolution), | ||
SolverMode::Coherence => { | ||
return ecx.evaluate_added_goals_and_make_canonical_response( | ||
Certainty::AMBIGUOUS, | ||
); | ||
} | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it even be unsound to return Err(NoSolution)
inside the solver during coherence, its very much true that a deafult impl will never allow us to actually normalize. For normalization outside of the solver this is wrong since we normalize shit even though we dont have to so making progress based of "this is required to actually normalize instead of just be wf" would be wrong.
I think we should have a comment on |
☔ The latest upstream changes (presumably #112351) made this pull request unmergeable. Please resolve the merge conflicts. |
still return ambiguity in coherence as this would otherwise be unsound.
The job Click to see the possible cause of the failure (guessed by this bot)
|
☔ The latest upstream changes (presumably #113086) made this pull request unmergeable. Please resolve the merge conflicts. |
closing this instead 😁 I am going to ignore specialization in the new solver for as long as possible |
…r-errors handle specialization in the new trait solver fixes rust-lang/trait-system-refactor-initiative#187 also fixes the regression in `plonky2_field` from rust-lang/trait-system-refactor-initiative#188 cc rust-lang#111994 r? `@compiler-errors`
…r-errors handle specialization in the new trait solver fixes rust-lang/trait-system-refactor-initiative#187 also fixes the regression in `plonky2_field` from rust-lang/trait-system-refactor-initiative#188 cc rust-lang#111994 r? ``@compiler-errors``
…r-errors handle specialization in the new trait solver fixes rust-lang/trait-system-refactor-initiative#187 also fixes the regression in `plonky2_field` from rust-lang/trait-system-refactor-initiative#188 cc rust-lang#111994 r? ```@compiler-errors```
Rollup merge of rust-lang#140306 - lcnr:specialization-new, r=compiler-errors handle specialization in the new trait solver fixes rust-lang/trait-system-refactor-initiative#187 also fixes the regression in `plonky2_field` from rust-lang/trait-system-refactor-initiative#188 cc rust-lang#111994 r? ```@compiler-errors```
still return ambiguity in coherence as this would otherwise be unsound.
r? @BoxyUwU