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

JS-158 Geneate Java API for ESTree #4725

Merged
merged 10 commits into from
Jun 7, 2024
Merged

JS-158 Geneate Java API for ESTree #4725

merged 10 commits into from
Jun 7, 2024

Conversation

saberduck
Copy link
Contributor

@saberduck saberduck commented Jun 4, 2024

Missing coverage is expected, it will be addressed after JS-159 and JS-160

Copy link
Contributor

@andrey-tyukin-sonarsource andrey-tyukin-sonarsource left a comment

Choose a reason for hiding this comment

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

One minor remark regarding naming conventions (type -> tpe?), and one question regarding Node - Expression relationship.

Copy link
Contributor

Choose a reason for hiding this comment

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

Except for a small manual modification in the generated file, it LGTM.

public record Location(Position start, Position end) {}

public sealed interface CallExpression extends Node {
Node callee();
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't understand why it's a Node. The spec says that callee and arguments are all Expressions.

This would result in a million unnecessary type casts.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

no problem to change, for some reason .d.ts says that it can be also Super https:/DefinitelyTyped/DefinitelyTyped/blob/master/types/estree/index.d.ts#L389

I am not sure which one is wrong, spec or dts

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, sorry, yeah, estree/index.d.ts is the ultimate source of truth here.

Copy link
Contributor

@andrey-tyukin-sonarsource andrey-tyukin-sonarsource left a comment

Choose a reason for hiding this comment

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

Scrolled through it, added a few comments here and there.

Some types of some child nodes seem unnecessarily lax, lots of child nodes are declared just as Node, even though they have a much more specific type in the .d.ts.

Note that Java allows to implement multiple sealed interfaces:

public class Multisealed {
  sealed interface A {}
  sealed interface B {}

  public record Foo() implements A, B {}
}

Could we maybe collect all | type unions, and convert them into sealed interfaces like ExpressionOrPropertyDefinition, and then let both Expression and PropertyDefinition implement the ExpressionOrPropertyDefinition? This should preserve the tight bounds on all types.

@@ -591,4 +591,4 @@ message SourceLocation {
message Position {
Copy link
Contributor

Choose a reason for hiding this comment

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

Having a comment somewhere whether it's all 0-based or 1-based certainly wouldn't hurt.

tools/estree/output/ESTree.java Outdated Show resolved Hide resolved
Copy link

sonarqube-next bot commented Jun 7, 2024

Quality Gate failed Quality Gate failed

Failed conditions
11 New issues
0.0% Coverage on New Code (required ≥ 90%)

See analysis details on SonarQube

Catch issues before they fail your Quality Gate with our IDE extension SonarLint SonarLint

@saberduck saberduck merged commit 6ccd736 into master Jun 7, 2024
15 of 17 checks passed
@saberduck saberduck deleted the JS-158-2 branch June 7, 2024 13:23
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.

4 participants