tunnelvisionlabs/antlr4ts

Generated TS files fail to compile

Opened this issue · 20 comments

Deleted user commented

image

I'm trying to use a basic grammar file to generate the ANTLR parser and lexer, but when running ""antlr4ts bSQLLexer.g4 bSQLParser.g4 -o ./src/ANTLR" I always get auto generated code with compile issues

Typescript is not a language that I am super familiar with, but I have tried an array of different manual edit work arounds and am having problems getting it to compile.

Here are the dependencies used in my package.json file
{ "scripts": { "antlr": "antlr4ts bSQLLexer.g4 bSQLParser.g4 -o ./src/ANTLR", "start": "webpack-dev-server --hot --open", "test": "mocha --reporter spec src/**/*.test.ts" }, "dependencies": { "antlr4ts": "^0.5.0-alpha.3", "monaco-editor-core": "^0.18.1", "react": "^16.8.6", "react-dom": "^16.8.6" }, "devDependencies": { "@types/chai": "^4.2.12", "@types/mocha": "^8.0.3", "@types/react": "^16.8.12", "@types/react-dom": "^16.8.3", "antlr4ts-cli": "^0.5.0-alpha.3", "chai": "^4.2.0", "css-loader": "^3.3.0", "html-webpack-plugin": "^3.2.0", "mocha": "^8.1.2", "style-loader": "^1.0.1", "ts-loader": "^5.3.3", "ts-node": "^9.0.0", "typescript": "^4.0.2", "webpack": "^4.29.6", "webpack-cli": "^3.3.0", "webpack-dev-server": "^3.2.1" } }

belaczek commented

+1
This is an issue since Typescript V4 issues an error on properties overriding accessors and vice versa.
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-0.html#properties-overriding-accessors-and-vice-versa-is-an-error

My temporary workaround is adding // @ts-nocheck at the beginning of all the generated files causing issues.

ColinTimBarndt commented

Is there any way to automate this temporary fix? This generator does not seem to support @headers. Otherwise this would have worked:

@header {
// @ts-nocheck
}
josejulio commented

I created a PR to fix this issue, could you verify if that fixes your issue also?
Not sure if we have to change any other getter.

belaczek commented

@josejulio Thank you for quick response. Checked the PR and it seems to cover all of our issues.

  • 👍3
ColinTimBarndt commented

I modified the antlr4ts-cli jar file with the PR and Typescript compiled without any errors.

ColinTimBarndt commented

I have encountered an error in one of the lines that are changed in the PR:

this.serializedATN = SomelanguageLexer._serializedATN;

Error:

TypeError: Cannot set property serializedATN of #<Recognizer> which has only a getter

This error is thrown because of this line of code in the abstract Recognizer class:

readonly serializedATN: string;

This means that more changes need to be made to the code to make it compatible to the newer version of Typescript (if I didn't make any mistakes on my side of course).

josejulio commented

Thanks, I probably modified something that didn't need to change.
Could you send a g4 file that reproduces the issue?

josejulio commented

I couldn't reproduce, i'm using typescript 4.0.2 and here is the output of the antlr4ts: https://gist.github.com/josejulio/8a7959ef6f7c646b88cd03bb24bf0ad6

Could you tell if is similar to the one you are getting?

edit: Also, how are you using the tool? Maybe I'm missing a flag?

ColinTimBarndt commented

I tried to parse this code:

fn main() {
  say("Hello World!");
}
josejulio commented

I might be approaching this bug on the wrong side.

Looking more closely, https://github.com/tunnelvisionlabs/antlr4ts/blob/master/src/Recognizer.ts#L117 is implementing the get method, but typescript(?) might be generating a readonly definition, which is weird on this current case.

There maybe is a way to tell typescript to not change it to readonly and allow implementors to overwrite it.

I'll create a typescript issue.

josejulio commented

typescript(?) might be generating a readonly definition

Looks like that's the behavior on (and before) typescript 3.6.2

edit: Updating typescript to 3.7.5 on this project seems to resolve the issue, but it also show other compile time errors on the lib itself. Will try to fix that.

josejulio commented

Updated the PR.
Now I'm upgrading to 4.0.2 and fixing a compile time error of the lib itself.

  • 👍2
MarkDGithub commented

Does anybody have a workaround for using this in a pipeline? I can't add // @ts-nocheck manually. It would be amazing if #486 would be merged.

mike-lischke commented

I mentioned that already in issue #479 but got no reply. Looks like this library doesn't get much love anymore from @sharwell or @BurtHarris. Not even automatically created security PRs are merged.

MarkDGithub commented

It seems like it's solved in the code with this pull request #490. When can we expect an updated npm package?

  • 👍5
friggeri commented

Any updates on this?

dmaffitt commented

I'd like to bump this issue, too. The good news is you have a lot of people interested in the library. The bad news is you have a lot of people interested in the library.

sharwell commented

I'm working on updating my forks to 4.9, starting with the Java release. I'm hoping I can get them published in the upcoming weeks.

  • 👍4
mmmkkaaayy commented

Hi @sharwell , I think there still might be something broken about this. I'm getting the error TS2611: 'ruleIndex' is defined as a property in class 'ParserRuleContext', but is overridden here in '<generated class>' as an accessor.. I'm using antlr4ts version ^0.5.0-alpha.4

In my generated class, I see public get ruleIndex(): number { return ...; }

In the RuleContext.js pulled in by npm, it's declared as get ruleIndex() { return -1; }
In RuleContext.d.ts pulled in by npm, it's declared as readonly ruleIndex: number;

So I think something is off with how TypeScript is generating type declarations. Perhaps this is relevant? https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#37-breaking-changes

FWIW, I got here from #488 which is more relevant to my specific issue

  • 👍1
  • 👀1