Add end position to ParserError #157
Conversation
|
This pull request introduces 7 alerts when merging 761366d into b907fc9 - view on LGTM.com new alerts:
|
| /** | ||
| * The source code to be parsed | ||
| */ | ||
| source: string |
There was a problem hiding this comment.
Why remove the semicolon in interface def?
There was a problem hiding this comment.
Not an actual reason. I'm just used to don't use semis.
There was a problem hiding this comment.
But they are there for our other interface definitions. I suggest to put it back here for consistency.
I am surprised "prettier" does not have an opinion on this syntax, it accepted both. But there is semi: true in our prettier.config.js, a "prettier" bug?
If you want to cleanup the type def to remove semicolon, pls create another PR to touch all of the interfaces, if @KFlash has no strong opinion on this syntax thing.
There was a problem hiding this comment.
@fisker should not semi:true in prettier.config.js enforce the semicolon here?
There was a problem hiding this comment.
yes, why don't we run prettier --check on CI?
There was a problem hiding this comment.
Got it, we got these in .prettierignore. @KFlash why we ignored those source files?
bench/v1.6.2/
bench/v2/
bench/v8-native-calls.js
node_modules/
dist/
src/token.ts
src/common.ts
src/chars.ts
src/lexer/charClassifier.ts
src/unicode.ts
package-lock.json
There was a problem hiding this comment.
the style get fucked up with Prettier and not lined. Regarding unicode.ts it will be a long list (2000 lines)
There was a problem hiding this comment.
@3cp Possible to use non-open source to replace Prettier? I got my own pretty printer we could use, but ain't going to open source that one.
There was a problem hiding this comment.
It could be weird for open source project to depend on non-open project.
| export function report(parser: ParserState, type: Errors, ...params: string[]): never { | ||
| throw new ParseError(parser.index, parser.line, parser.column, type, ...params); | ||
| export function report(parser: ParserState, context: Context, node: Node, type: Errors, ...params: string[]): never { | ||
| const end = finishNode(parser, context, parser.index, parser.line, parser.column, node).loc?.end; |
There was a problem hiding this comment.
The finishNode mutates nothing on parser: ParserState. If you look into the implementation, the loc.end is just
end: {
line: parser.startLine,
column: parser.startColumn
}
Which you can directly get from parser.
Also, the availability of loc.end in finishNode depends on OptionsLoc, but you can always get parser.startLine directly.
No description provided.