8000 Refactoring: Generic notion of CheckingPhase for the IR checkers. by sjrd · Pull Request #5120 · scala-js/scala-js · GitHub
[go: up one dir, main page]

Skip to content

Refactoring: Generic notion of CheckingPhase for the IR checkers. #5120

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

8000
Merged
merged 1 commit into from
Feb 3, 2025

Conversation

sjrd
Copy link
Member
@sjrd sjrd commented Jan 22, 2025

Extracted from #5101.

I have not yet included the following comments:

However, I did add a second commit that removes the distinction between Emitter(afterOptimizer = true/false). There's only Emitter now, and it always accepts optimized IR, even if it is actually run without the optimizer.

@sjrd sjrd requested a review from gzm0 January 22, 2025 16:33
@sjrd
Copy link
Member Author
sjrd commented Jan 25, 2025

@gzm0 I added a commit that switches to using the previous phase rather than the next phase. That means we're back to using checkIR: Boolean instead of checkIRFor: Option[CheckingPhase] as argument to the phases. This does result in a much smaller diff overall, so on that basis alone, it looks bette 8000 r this way.

Regarding your other comment from the previous PR:

I know I'm contradicting myself a bit here, but would it make sense to just have factories / constants for the individual CheckingPhases and pass a FeatureSet around? (Yes, we'd need a "failure is a bug" feature set, but maybe that's an OK trade-off).

I don't think that would be better. For one thing, we would need to make FeatureSet public. That would defeat one of your earlier comments to keep the knowledge of what is valid when inside package checker.

Copy link
Contributor
@gzm0 gzm0 left a comment

Choose a reason for hiding this comment

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

Only some optional nits. LGTM after squashing.

* When checking IR (with `ClassDefChecker` or `IRChecker`), different nodes
* and transients are allowed between different phases. The `CheckingPhase`
* records the *previous* phase to run before the check. We are therefore
* checking that the IR is a valid *output* to the target phase.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
* checking that the IR is a valid *output* to the target phase.
* checking that the IR is a valid *output* of the target phase.

(but I'm not entirely sure).

private val analyzer =
new Analyzer(config, initial = false, checkIR = checkIR, failOnError = true, irLoader)
private val analyzer = {
val checkIRFor = Some(CheckingPhase.Optimizer).filter(_ => checkIR)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
val checkIRFor = Some(CheckingPhase.Optimizer).filter(_ => checkIR)
val checkIRFor = if (checkIR) Some(CheckingPhase.Optimizer) else None

? even if a bit longer, IMO easier to grok.

private val analyzer =
new Analyzer(config, initial = true, checkIR = checkIR, failOnError = true, irLoader)
private val analyzer = {
val checkIRFor = Some(CheckingPhase.Compiler).filter(_ => checkIR)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
val ch 8000 eckIRFor = Some(CheckingPhase.Compiler).filter(_ => checkIR)
val checkIRFor = if (checkIR) Some(CheckingPhase.Compiler) else None

? even if a bit longer, IMO easier to grok.

We previously had two boolean options for deciding what IR is
allowed or not between phases. Of the four possible combinations
of values, one was actually invalid.

With the introduction of the desugarer, there would have been
*three* such boolean options. Only 4 out of their 8 combinations
would have been valid.

We now introduce a generic concept of `CheckingPhase`. Some IR
features are allowed as output of each `CheckingPhase`. Since the
`ClassDefChecker` and `IRChecker` must agree on what features are
valid when, we factor that logic into `FeatureSet`. It represents
a set of logical features, and can compute which set is valid for
each phase.
@sjrd sjrd force-pushed the refactor-checking-phase branch from b341cc9 to 2a77c9c Compare February 2, 2025 21:49
@sjrd sjrd merged commit f014e0e into scala-js:main Feb 3, 2025
3 checks passed
@sjrd sjrd deleted the refactor-checking-phase branch February 3, 2025 04:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
< 3BE7 !-- -->
Development

Successfully merging this pull request may close these issues.

2 participants
0