Skip to content
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

Skip const-eval if evaluatable predicate is trivial #127242

Conversation

dingxiangfei2009
Copy link
Contributor

@dingxiangfei2009 dingxiangfei2009 commented Jul 2, 2024

It appears that ConstEvaluatable predicate is given already in ParamEnv during type-checking in well-formness checks. This is an attempt at simplifying the checks.

Fix #123959

@rustbot
Copy link
Collaborator

rustbot commented Jul 2, 2024

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@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 Jul 2, 2024
@rust-log-analyzer

This comment has been minimized.

@dingxiangfei2009 dingxiangfei2009 force-pushed the skip-const-resolve-if-trivially-evaluatable branch from 6f5ea7f to 763bd0c Compare July 2, 2024 15:44
@rust-log-analyzer

This comment has been minimized.

@dingxiangfei2009 dingxiangfei2009 force-pushed the skip-const-resolve-if-trivially-evaluatable branch from 763bd0c to 05c8ece Compare July 2, 2024 18:10
@dingxiangfei2009 dingxiangfei2009 marked this pull request as ready for review July 5, 2024 09:22
@rustbot
Copy link
Collaborator

rustbot commented Jul 5, 2024

Some changes occurred in const_evaluatable.rs

cc @BoxyUwU

Copy link
Member

@BoxyUwU BoxyUwU left a comment

Choose a reason for hiding this comment

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

I think there is not much point in landing this for a few reasons:

  1. generic_const_exprs is very unstable and this is likely to not be the final design so investing time (and code complexity) into small performance optimizations does not seem worth it to me
  2. Logic for equating consts already has a similar special case to this that will check for == and short circuit and return Ok if its true.
  3. I would expect that this method of solving that ICE is masking an underlying issue, but I would have to poke at the example a bit more to figure out exactly what's going on

Regardless thanks for the interest in const generics :3


if tcx.features().generic_const_exprs {
let ct = tcx.expand_abstract_consts(unexpanded_ct);

if trivially_satisfied_from_param_env(ct, param_env) {
Copy link
Member

@BoxyUwU BoxyUwU Jul 13, 2024

Choose a reason for hiding this comment

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

This would have had to go before the expand_abstract_consts call as otherwise its never going to find any matches in the env since abstract consts arent expanded in the ParamEnv :3

@bors
Copy link
Contributor

bors commented Jul 19, 2024

☔ The latest upstream changes (presumably #125915) made this pull request unmergeable. Please resolve the merge conflicts.

@BoxyUwU
Copy link
Member

BoxyUwU commented Sep 16, 2024

Closing this so it's not in my list of assigned PRs anymore 😅 Feel free to reopen if you disagree with my comments and would like to continue this

@BoxyUwU BoxyUwU closed this Sep 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ICE when using offset_of! in generic_const_exprs
5 participants