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

Fixes most of Kotlin runtime tests #8

Merged

Conversation

ftomassetti
Copy link
Collaborator

This is a PR on the PR #6

I tried to fix as many failing tests as possible, going from 36 to 3.
The test fixed were fixed by revising escaping rules, and by renaming getters not to clash with auto-generated getters for properties.

@@ -959,7 +959,7 @@ public open class <lexer.name>(input: CharStream) : <superClass; null="Lexer">(i
public object Modes {
public const val DEFAULT_MODE: Int = 0
<if(rest(lexer.modes))>
<rest(lexer.modes):{m | public const val <m>: Int = <i>}; separator="\n">
<rest(lexer.modes):{m | public const val MODE_<m; format="upper">: Int = <i>}; separator="\n">
Copy link
Collaborator

@lppedd lppedd Jan 25, 2024

Choose a reason for hiding this comment

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

Just wondering why this is prefixed with MODE_ now.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Probably this is not necessary. If the name is uppercase it should not clash with keywords anyway

Copy link
Collaborator

Choose a reason for hiding this comment

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

@ftomassetti yup, that's the same logic we use for the other "namespaces".

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I think we should either:

  • remove the _MODE suffix from DEFAULT_MODE and the MODE_ prefix from the other modes
  • keep DEFAULT_MODE and change MODE_<m; format="upper"> into <m; format="upper">_MODE

What do you think @lppedd ? Any preference?

Copy link
Collaborator

@lppedd lppedd Jan 25, 2024

Choose a reason for hiding this comment

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

@ftomassetti I'd say the most idiomatic is option 1

remove the MODE suffix from DEFAULT_MODE and the MODE prefix from the other modes

The suffix (or prefix) is redundant inside a Modes namespace imo.

You can keep <m; format="upper"> tho, so we are sure they're always uppercased and no conflict will ever arise.
Modes will always require an uppercase initial character at the .g4 level right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Then I will remove the prefix MODE_ and add a separate issue for renaming DEFAULT_MODE as it would impact several files and I think this PR should be kept minimal

Copy link
Collaborator

Choose a reason for hiding this comment

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

Sounds good!

@@ -84,7 +84,7 @@ public Map<Character, String> getTargetCharValueEscape() {
public String getTokenTypeAsTargetLabel(Grammar g, int ttype) {
// All tokens are namespaced inside a Tokens object.
// Here we simply force the qualification
return "Tokens." + super.getTokenTypeAsTargetLabel(g, ttype);
return super.getTokenTypeAsTargetLabel(g, ttype);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Nice one with this one. I'd just remove this method at this point.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thank you!

Signed-off-by: Federico Tomassetti <federico@strumenta.com>
Signed-off-by: Federico Tomassetti <federico@strumenta.com>
@KvanTTT
Copy link
Member

KvanTTT commented Jan 26, 2024

Thanks, amazing work! I'll review and merge close to this weekends.

@KvanTTT
Copy link
Member

KvanTTT commented Jan 27, 2024

Is it ready to merge?

@ftomassetti
Copy link
Collaborator Author

Yes, for me it is

@KvanTTT KvanTTT merged commit 152ed61 into antlr:integrate-kotlin-runtime Jan 27, 2024
1 check passed
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.

3 participants