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

Don't normalize in AppliedType#superType #15453

Merged
merged 7 commits into from
Jun 17, 2022
Merged

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Jun 15, 2022

superType is intended to be a lightweight method, so it should not include normalize. I ran into this when I tried to rename more calls to underlying to superType and running into cyclic reference errors. The problem is that we really need these renamings for correctness. So to be able to do this, normalize has to be decoupled from superType first.

@odersky odersky marked this pull request as ready for review June 15, 2022 15:42
@odersky
Copy link
Contributor Author

odersky commented Jun 15, 2022

test performance please

@dottybot
Copy link
Member

performance test scheduled: 5 job(s) in queue, 1 running.

@odersky
Copy link
Contributor Author

odersky commented Jun 15, 2022

There are a number of smaller changes and one big: Move tryCompiletimeConstantFold to a new TypeEval object. The function itself was not changed, except updating the syntax to the recommended Scala 3 layout.

Comment on lines 4181 to 4184
// We need to invalidate the cache when the period changes because the
// case `TermRef` of `Type#isStable` reads denotations, which depend on
// the period. See docs/_docs/internals/periods.md for more information.
if myIsStablePeriod != ctx.period then
if myisStableRunId != ctx.runId then
Copy link
Member

Choose a reason for hiding this comment

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

Looks like the comment needs to be updated to reflect the code, but I don't understand why this is correct since StableRealizable is not a FromStartFlags or AfterLoadFlags.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

StableRealizable is computed on completion, and the critical window is covered by is(Provisional).

Copy link
Member

@mbovel mbovel Jun 15, 2022

Choose a reason for hiding this comment

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

      // We need to invalidate the cache when the run changes because the case
      // `TermRef` of `Type#isStable` reads denotations, which depend on the
      // run. See docs/_docs/internals/periods.md for more information. We do
      // not need to check the phase because once a type is not provisional, its
      // stability should not change anymore.

Would this updated comment make sense?

@mbovel
Copy link
Member

mbovel commented Jun 15, 2022

Side note: I tried to add a .git-blame-ignore-revs to ignore cd78e06 but this unfortunately does not seem to work when moving content from one file to another.

@dottybot
Copy link
Member

Performance test finished successfully:

Visit https://dotty-bench.epfl.ch/15453/ to see the changes.

Benchmarks is based on merging with main (520beb2)

@odersky
Copy link
Contributor Author

odersky commented Jun 15, 2022

What's up with the MiMa failures? There'a bunch of Tuple related stuff that's now flagged on all new PRs.

@dwijnand
Copy link
Member

Looks like they come from #15454 being force merged?

@nicolasstucki
Copy link
Contributor

To fix the MiMa tests, we should be able to re-run the tests after #15457 is merged (no-rebase needed).

1 similar comment
@nicolasstucki
Copy link
Contributor

To fix the MiMa tests, we should be able to re-run the tests after #15457 is merged (no-rebase needed).

@mbovel mbovel merged commit 13d9359 into scala:main Jun 17, 2022
@mbovel mbovel deleted the fix-superType branch June 17, 2022 07:25
@mbovel
Copy link
Member

mbovel commented Jun 20, 2022

As predicted in #14864 (comment), caching normalize greatly improve the runtime of some compile-time operations benchmarks. Especially this one:

image

It also improves performance of one Tuple benchmark:

image

Benchmarks from https://dotty-bench.epfl.ch, lower is better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants