Skip to content

Defer evaluating type system constants when they use infers or params #140553

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

Merged
merged 5 commits into from
May 23, 2025

Conversation

BoxyUwU
Copy link
Member

@BoxyUwU BoxyUwU commented May 1, 2025

Split out of #137972, the parts necessary for associated const equality and min generic const args to make progress and have correct semantics around when CTFE is invoked. According to a previous perf run of adding the new const_arg_kind query we should expect minor regressions here.

I think this is acceptable as we should be able to remove this query relatively soon once mgca is more complete as we'll then be able to implement GCE in terms of mgca and rip out GCEConst at which point it's trivial to determine what kind of anon const we're dealing with (either it has generics and is a repeat expr hack, or it doesnt and is a normal anon const).

This should only affect unstable code as we handle repeat exprs specially and those are the only kinds of type system consts that are allowed to make use of generic parameters.

Fixes #133066
Fixes #133199
Fixes #136894
Fixes #137813

r? compiler-errors

@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 May 1, 2025
@rustbot
Copy link
Collaborator

rustbot commented May 1, 2025

This PR changes a file inside tests/crashes. If a crash was fixed, please move into the corresponding ui subdir and add 'Fixes #' to the PR description to autoclose the issue upon merge.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Collaborator

bors commented May 6, 2025

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

@BoxyUwU BoxyUwU force-pushed the defer_type_system_ctfe branch from de3acb8 to 2784c3c Compare May 6, 2025 15:36
@BoxyUwU BoxyUwU force-pushed the defer_type_system_ctfe branch from 2784c3c to bb7e27a Compare May 21, 2025 19:28
Copy link
Member

@compiler-errors compiler-errors left a comment

Choose a reason for hiding this comment

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

:>

@compiler-errors
Copy link
Member

cool

@bors r+ rollup=never

@bors
Copy link
Collaborator

bors commented May 22, 2025

📌 Commit bb7e27a has been approved by compiler-errors

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 22, 2025
@BoxyUwU
Copy link
Member Author

BoxyUwU commented May 22, 2025

@bors r- :<
I just remembered that we smuggle const patterns into ty::Const so I don't think:

This should only affect unstable code as we handle repeat exprs specially and those are the only kinds of type system consts that are allowed to make use of generic parameters.

is true. at the very least I want to make sure I understand why this doesnt break anything.. because I would probably expect it to

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 22, 2025
@BoxyUwU
Copy link
Member Author

BoxyUwU commented May 22, 2025

fn unevaluated_to_pat(
...
        // try to resolve e.g. associated constants to their definition on an impl, and then
        // evaluate the const.
        let valtree = match self.tcx.const_eval_resolve_for_typeck(typing_env, uv, self.span) {

We don't invoke type system norm on these constants though we just directly call into const eval resolve so this is fine. I.e. we won't break the following code:

trait Trait { const ASSOC: usize; }

impl<T> Trait for T {
    const ASSOC: usize = 10;
}

fn bar<T>(a: usize) {
    match a {
        <T as Trait>::ASSOC => (),
        _ => (),
    }
}

Where we try to evaluate <T as Trait>::ASSOC which this PR would reject if going through evaluate_const as it syntactically makes use of a generic parameter.

@BoxyUwU BoxyUwU force-pushed the defer_type_system_ctfe branch from bb7e27a to 4f2e93a Compare May 22, 2025 11:27
@BoxyUwU
Copy link
Member Author

BoxyUwU commented May 22, 2025

I think tests/ui/const-generics/const_eval_unchecked_doesnt_fire_patterns.rs would fail if we did go through type system norm instead of manually calling into ctfe so I don't need to add a test here 🤔

@BoxyUwU BoxyUwU force-pushed the defer_type_system_ctfe branch from 4f2e93a to fdccb42 Compare May 22, 2025 11:53
@BoxyUwU
Copy link
Member Author

BoxyUwU commented May 22, 2025

Added a test anyway because it seems nice to have one specifically for this case instead of only having a test that happens to fail but was meant for something else. @rustbot ready

(I checked locally what tests fail if I change us to use type system norm to evaluate patterns and also confirmed that the test I added fails if we do that)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 22, 2025
@compiler-errors
Copy link
Member

@bors r+

@bors
Copy link
Collaborator

bors commented May 22, 2025

📌 Commit fdccb42 has been approved by compiler-errors

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 22, 2025
@bors
Copy link
Collaborator

bors commented May 23, 2025

⌛ Testing commit fdccb42 with merge 52bf0cf...

@bors
Copy link
Collaborator

bors commented May 23, 2025

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 52bf0cf to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 23, 2025
@bors bors merged commit 52bf0cf into rust-lang:master May 23, 2025
7 checks passed
@rustbot rustbot added this to the 1.89.0 milestone May 23, 2025
Copy link

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing e7f4317 (parent) -> 52bf0cf (this PR)

Test differences

Show 16 test diffs

Stage 1

  • [crashes] tests/crashes/133199.rs: pass -> [missing] (J1)
  • [crashes] tests/crashes/136894.rs: pass -> [missing] (J1)
  • [crashes] tests/crashes/137813.rs: pass -> [missing] (J1)
  • [ui] tests/ui/const-generics/associated_const_equality/equality_bound_with_infer.rs: [missing] -> pass (J1)
  • [ui] tests/ui/const-generics/associated_const_equality/unconstrained_impl_param.rs: [missing] -> pass (J1)
  • [ui] tests/ui/const-generics/generic_const_exprs/cross-crate-2.rs: [missing] -> pass (J1)
  • [ui] tests/ui/const-generics/generic_const_exprs/serializing_error_guaranteed.rs: [missing] -> pass (J1)
  • [ui] tests/ui/pattern/unused-parameters-const-pattern.rs: [missing] -> pass (J1)

Stage 2

  • [ui] tests/ui/const-generics/associated_const_equality/equality_bound_with_infer.rs: [missing] -> pass (J0)
  • [ui] tests/ui/const-generics/associated_const_equality/unconstrained_impl_param.rs: [missing] -> pass (J0)
  • [ui] tests/ui/const-generics/generic_const_exprs/cross-crate-2.rs: [missing] -> pass (J0)
  • [ui] tests/ui/const-generics/generic_const_exprs/serializing_error_guaranteed.rs: [missing] -> pass (J0)
  • [ui] tests/ui/pattern/unused-parameters-const-pattern.rs: [missing] -> pass (J0)
  • [crashes] tests/crashes/133199.rs: pass -> [missing] (J2)
  • [crashes] tests/crashes/136894.rs: pass -> [missing] (J2)
  • [crashes] tests/crashes/137813.rs: pass -> [missing] (J2)

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 52bf0cf795dfecc8b929ebb1c1e2545c3f41d4c9 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. dist-apple-various: 8665.5s -> 7002.1s (-19.2%)
  2. dist-aarch64-msvc: 8288.7s -> 9669.4s (16.7%)
  3. x86_64-apple-1: 7578.5s -> 6400.5s (-15.5%)
  4. dist-i686-linux: 5886.9s -> 6326.4s (7.5%)
  5. dist-aarch64-apple: 4998.1s -> 5338.5s (6.8%)
  6. x86_64-mingw-2: 7090.8s -> 7553.1s (6.5%)
  7. x86_64-gnu-llvm-19-3: 7313.1s -> 6873.7s (-6.0%)
  8. x86_64-rust-for-linux: 2627.5s -> 2772.6s (5.5%)
  9. x86_64-msvc-ext1: 7440.2s -> 7080.8s (-4.8%)
  10. dist-ohos-aarch64: 4468.9s -> 4659.3s (4.3%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (52bf0cf): comparison URL.

Overall result: ❌ regressions - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

  • If the regression was expected or you think it can be justified,
    please write a comment with sufficient written justification, and add
    @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
  • If you think that you know of a way to resolve the regression, try to create
    a new PR with a fix for the regression.
  • If you do not understand the regression or you think that it is just noise,
    you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
    were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
0.3% [0.1%, 0.5%] 15
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.3% [0.1%, 0.5%] 15

Max RSS (memory usage)

Results (primary 0.2%, secondary 4.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
1.1% [0.7%, 2.0%] 5
Regressions ❌
(secondary)
4.2% [2.3%, 7.8%] 3
Improvements ✅
(primary)
-1.3% [-1.8%, -0.9%] 3
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.2% [-1.8%, 2.0%] 8

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

Results (primary 0.4%, secondary 0.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.4% [0.0%, 1.1%] 120
Regressions ❌
(secondary)
0.4% [0.0%, 1.1%] 22
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.4% [0.0%, 1.1%] 120

Bootstrap: 778.581s -> 777.568s (-0.13%)
Artifact size: 365.44 MiB -> 365.56 MiB (0.03%)

@rustbot rustbot added the perf-regression Performance regression. label May 23, 2025
@Kobzol
Copy link
Contributor

Kobzol commented May 23, 2025

The binary size regressions correspond to metadata getting larger, not actual binary size increases.

compiler-errors pushed a commit to compiler-errors/rust that referenced this pull request May 23, 2025
…mpiler-errors

Defer evaluating type system constants when they use infers or params

Split out of rust-lang#137972, the parts necessary for associated const equality and min generic const args to make progress and have correct semantics around when CTFE is invoked. According to a [previous perf run](https://perf.rust-lang.org/compare.html?start=93257e2d20809d82d1bc0fcc1942480d1a66d7cd&end=01b4cbf0f47c3f782330db88fa5ba199bba1f8a2&stat=instructions:u) of adding the new `const_arg_kind` query we should expect minor regressions here.

I think this is acceptable as we should be able to remove this query relatively soon once mgca is more complete as we'll then be able to implement GCE in terms of mgca and rip out `GCEConst` at which point it's trivial to determine what kind of anon const we're dealing with (either it has generics and is a repeat expr hack, or it doesnt and is a normal anon const).

This should only affect unstable code as we handle repeat exprs specially and those are the only kinds of type system consts that are allowed to make use of generic parameters.

Fixes rust-lang#133066
Fixes rust-lang#133199
Fixes rust-lang#136894
Fixes rust-lang#137813

r? compiler-errors
@rylev
Copy link
Member

rylev commented May 27, 2025

@BoxyUwU @compiler-errors looking at some of the regressions in detail it does look like we're spending more time in generate_crate_metadata.

I see that perf regressions were expected. Are we fine with the magnitude seen here?

@compiler-errors
Copy link
Member

Yeah, this is a consequence of encoding a new query into metadata. I believe that this perf regression is okay.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. 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.
Projects
None yet
8 participants