tunnelvisionlabs / antlr4ts

Optimized TypeScript target for ANTLR 4
Other
624 stars 106 forks source link

Generated TS files fail to compile #485

Open ghost opened 3 years ago

ghost commented 3 years ago

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 3 years ago

+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 3 years ago

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 3 years ago

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 3 years ago

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

ColinTimBarndt commented 3 years ago

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

ColinTimBarndt commented 3 years ago

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 3 years ago

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

ColinTimBarndt commented 3 years ago

Here you go: https://gist.github.com/ColinTimBarndt/aebc51177b93b7c6c002bb765ff1a941

josejulio commented 3 years ago

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 3 years ago

I tried to parse this code:

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

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 3 years ago

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 3 years ago

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

MarkDGithub commented 3 years ago

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 3 years ago

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 3 years ago

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

friggeri commented 3 years ago

Any updates on this?

dmaffitt commented 3 years ago

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 3 years ago

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.

mmmkkaaayy commented 2 years ago

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