give next-solver's evaluate_const its own try_evaluate_const logic - #161418
give next-solver's evaluate_const its own try_evaluate_const logic#161418zedddie wants to merge 4 commits into
evaluate_const its own try_evaluate_const logic#161418Conversation
rustbot
added
S-waiting-on-author
|
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
00a3838 to
92b2dea
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
92b2dea to
5a6ab62
Compare
This comment has been minimized.
This comment has been minimized.
5a6ab62 to
c40c0cd
Compare
This comment has been minimized.
This comment has been minimized.
c40c0cd to
67b25fa
Compare
67b25fa to
c814483
Compare
zedddie
changed the title
evaluate_const its own try_evaluate_const logic
rustbot
added
S-waiting-on-review
There was a problem hiding this comment.
would you mind merging evaluate_const and evaluate_const_and_instantiate_projection_term into a single function.
The logic in compute_const_evaluatable_goal will have to change to prove a nested Projection goal instead of manually calling evaluate_const, that seems like a nice cleanup regardless :3
There was a problem hiding this comment.
dont mind if u want to do this in a future PR, but also do think it would be nice to do in this PR as its kind of one big "smush all the logic into one place" change
| typing_env: Self::TypingEnv, | ||
| ct: ty::AliasConst<'tcx>, | ||
| span: Self::Span, | ||
| ) -> Result<Result<Self::ValTree, Self::Ty>, Option<Self::ErrorGuaranteed>> { |
There was a problem hiding this comment.
@khyperia's right that this is a scary return type :3 I think we would ideally make this a bespoke enum and maybe even change the original const_eval_resolve_for_typeck query to return it 🤔
I think that can be a future PR tho
|
@rustbot author very coolio :3 |
rustbot
removed
the
S-waiting-on-review
rustbot
added
the
S-waiting-on-author
|
Reminder, once the PR becomes ready for a review, use |
4 participants
Currently evaluating type-level constants is convoluted as code is split in a lot of scattered functions across compiler which makes it hard to reason about. This PR refactors next-solver's CTFE entry point and should not change any behavior.
for context see #project-const-generics > evaluate_const is scary
r? BoxyUwU