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

Report RegExp errors in grammar check, use Annex B grammar #58295

Merged
merged 7 commits into from Apr 24, 2024

Conversation

rbuckton
Copy link
Member

This moves extended regular expression syntax checks to a grammar check. This ensures that RegExp grammar checks don't prevent type checking and allows them to be overridden via // @ts-ignore when necessary.

This also weakens the grammar check to use the productions and semantics in Annex B. This uses a boolean value to choose whether to use Annex B grammar in case we want to make this configurable, but for now the only place this is defined is guaranteed to be true.

Related #58287

@jakebailey
Copy link
Member

Theoretically this should net some "missing" errors

@typescript-bot user test this
@typescript-bot run dt
@typescript-bot test top400

@typescript-bot
Copy link
Collaborator

typescript-bot commented Apr 23, 2024

Starting jobs; this comment will be updated as builds start and complete.

Command Status Results
user test this ✅ Started 👀 Results
run dt ✅ Started
test top400 ✅ Started 👀 Results

@typescript-bot
Copy link
Collaborator

@jakebailey Here are the results of running the user tests comparing main and refs/pull/58295/merge:

Something interesting changed - please have a look.

Details

azure-sdk

/mnt/ts_downloads/_/m/azure-sdk/build.sh

  • [MISSING] error TS2322: Type 'string' is not assignable to type 'never'.
    • /mnt/ts_downloads/_/m/azure-sdk/test/narrowedTypes.ts(59,9)
    • /mnt/ts_downloads/_/m/azure-sdk/test/narrowedTypes.ts(213,9)
    • /mnt/ts_downloads/_/m/azure-sdk/test/narrowedTypes.ts(254,11)

puppeteer

tsconfig.base.json

packages/puppeteer-core/tsconfig.json

pyright

/mnt/ts_downloads/_/m/pyright/build.sh

  • [MISSING] error TS1516: A character class range must not be bounded by another character class.
    • /mnt/ts_downloads/_/m/pyright/pyright: ../pyright-internal/src/parser/tokenizer.ts(1271,94)
    • /mnt/ts_downloads/_/m/pyright/pyright: ../pyright-internal/src/parser/tokenizer.ts(1290,100)
    • /mnt/ts_downloads/_/m/pyright/pyright-internal: src/parser/tokenizer.ts(1271,94)
    • /mnt/ts_downloads/_/m/pyright/pyright-internal: src/parser/tokenizer.ts(1290,100)
    • /mnt/ts_downloads/_/m/pyright/vscode-pyright: ../pyright-internal/src/parser/tokenizer.ts(1271,94)
    • /mnt/ts_downloads/_/m/pyright/vscode-pyright: ../pyright-internal/src/parser/tokenizer.ts(1290,100)

url-search-params

/mnt/ts_downloads/_/m/url-search-params/tsconfig.json

  • [MISSING] error TS2629: Cannot assign to 'URLSearchParams' because it is a class.
    • /mnt/ts_downloads/_/m/url-search-params/node_modules/url-search-params/build/url-search-params.node.js(174,1)

@typescript-bot
Copy link
Collaborator

@jakebailey Here are the results of running the top 400 repos comparing main and refs/pull/58295/merge:

Something interesting changed - please have a look.

Details

tinacms/tinacms

11 of 24 projects failed to build with the old tsc and were ignored

packages/next-tinacms-s3/tsconfig.json

packages/next-tinacms-dos/tsconfig.json

packages/next-tinacms-cloudinary/tsconfig.json

packages/@tinacms/vercel-previews/tsconfig.json

@graphemecluster
Copy link
Contributor

@rbuckton
Copy link
Member Author

In general, I think there might be a happy medium between general specification strictness and Annex B looseness. For example, we probably want to treat \1, \2, etc., as an error when they are either higher than the number of capturing left parens or are used in a character class as they are ambiguous. It's likely that the user expected \2 to be treated as a backreference, and most of the cases where users have written [^\2] seem to be due to a misunderstanding about how character classes work. Erroring in these cases makes sense as it would point out the misuse.

Cases like [\w-_], where a minus (-) appears in a character class before or after a character class escape like \w or \d, are usually the result of a user conflating - as a potential character to match vs - to denote a range. Annex B would treat [\w-_] the same as [-\w_], so there's no ambiguity with that syntax. The only ambiguity here would be one that strict checking wouldn't catch, such as [a-_] where the user may have intended to use - as a character to match against rather than a range. There may be value in reporting an error for the [\w-_] case to make users take more notice of the [a-_] case, but that's not going to be a reliable check.

Most of the other Annex B checks we may want to just leave out in favor of stricter parsing as they generally indicate invalid syntax that you're less likely to actually come across in practice.

The upside of doing this during the grammar check pass is that if a user really wants to use that syntax then they have the option to annotate the line with // @ts-ignore.

There are a few other things I want to explore either in this PR or another follow up PR to cut down on the number --target-specific errors, either by just treating them as suggestion diagnostics for now, or introducing a compiler flag to give the users control over reporting such errors broadly as opposed to just using // @ts-ignore to silence them on a case by case basis.

@rbuckton
Copy link
Member Author

I'll discuss whether we should use stricter rules than Annex B in the next Design Meeting, with any changes coming in a follow-up PR.

@rbuckton
Copy link
Member Author

@typescript-bot perf test
@typescript-bot run dt

@typescript-bot
Copy link
Collaborator

typescript-bot commented Apr 24, 2024

Starting jobs; this comment will be updated as builds start and complete.

Command Status Results
perf test ✅ Started 👀 Results
run dt ✅ Started 👀 Results

@typescript-bot
Copy link
Collaborator

Hey @rbuckton, the results of running the DT tests are ready.

There were interesting changes:

Branch only errors:

Package: codemirror
Error:

Error: Debug Failure. False expression.
Occurred while linting /mnt/vss/_work/1/DefinitelyTyped/types/codemirror/test/addon/mode/simple.ts:1
Rule: "@definitelytyped/expect"
    at checkGrammarRegularExpressionLiteral (/mnt/vss/_work/1/s/built/local/typescript.js:75972:13)
    at checkRegularExpressionLiteral (/mnt/vss/_work/1/s/built/local/typescript.js:75982:5)
    at checkExpressionWorker (/mnt/vss/_work/1/s/built/local/typescript.js:82919:16)
    at checkExpression (/mnt/vss/_work/1/s/built/local/typescript.js:82845:32)
    at checkExpressionForMutableLocation (/mnt/vss/_work/1/s/built/local/typescript.js:82603:18)
    at checkPropertyAssignment (/mnt/vss/_work/1/s/built/local/typescript.js:82619:12)
    at checkObjectLiteral (/mnt/vss/_work/1/s/built/local/typescript.js:76200:71)
    at checkExpressionWorker (/mnt/vss/_work/1/s/built/local/typescript.js:82923:16)
    at checkExpression (/mnt/vss/_work/1/s/built/local/typescript.js:82845:32)
    at checkExpressionForMutableLocation (/mnt/vss/_work/1/s/built/local/typescript.js:82603:18)

You can check the log here.

@jakebailey
Copy link
Member

Hm, crash on the DT code, it looks. Definitely relevant.

@typescript-bot
Copy link
Collaborator

@rbuckton
The results of the perf run you requested are in!

Here they are:

tsc

Comparison Report - baseline..pr
Metric baseline pr Delta Best Worst p-value
Compiler-Unions - node (v18.15.0, x64)
Errors 30 30 ~ ~ ~ p=1.000 n=6
Symbols 62,154 62,154 ~ ~ ~ p=1.000 n=6
Types 50,273 50,273 ~ ~ ~ p=1.000 n=6
Memory used 192,705k (± 0.74%) 193,991k (± 0.97%) ~ 192,104k 195,808k p=0.128 n=6
Parse Time 1.64s (± 0.94%) 1.65s (± 0.77%) ~ 1.64s 1.67s p=0.328 n=6
Bind Time 0.87s (± 1.13%) 0.87s (± 0.60%) ~ 0.86s 0.87s p=0.931 n=6
Check Time 11.35s (± 0.14%) 11.34s (± 0.48%) ~ 11.26s 11.41s p=0.630 n=6
Emit Time 3.15s (± 0.52%) 3.14s (± 0.73%) ~ 3.10s 3.17s p=0.870 n=6
Total Time 17.01s (± 0.12%) 16.99s (± 0.36%) ~ 16.92s 17.06s p=0.686 n=6
angular-1 - node (v18.15.0, x64)
Errors 5 0 ~ ~ ~ p=1.000 n=6+0
Symbols 945,172 0 ~ ~ ~ p=1.000 n=6+0
Types 408,068 0 ~ ~ ~ p=1.000 n=6+0
Memory used 1,221,853k (± 0.01%) 0k ~ ~ ~ p=1.000 n=6+0
Parse Time 8.29s (± 0.28%) 0s ~ ~ ~ p=1.000 n=6+0
Bind Time 2.23s (± 0.47%) 0s ~ ~ ~ p=1.000 n=6+0
Check Time 36.34s (± 0.52%) 0s ~ ~ ~ p=1.000 n=6+0
Emit Time 17.39s (± 0.85%) 0s ~ ~ ~ p=1.000 n=6+0
Total Time 64.24s (± 0.34%) 0s ~ ~ ~ p=1.000 n=6+0
mui-docs - node (v18.15.0, x64)
Errors 5 0 ~ ~ ~ p=1.000 n=6+0
Symbols 1,954,598 0 ~ ~ ~ p=1.000 n=6+0
Types 676,387 0 ~ ~ ~ p=1.000 n=6+0
Memory used 1,753,234k (± 0.00%) 0k ~ ~ ~ p=1.000 n=6+0
Parse Time 10.04s (± 0.66%) 0s ~ ~ ~ p=1.000 n=6+0
Bind Time 3.29s (± 5.84%) 0s ~ ~ ~ p=1.000 n=6+0
Check Time 82.04s (± 0.33%) 0s ~ ~ ~ p=1.000 n=6+0
Emit Time 0.20s 0s ~ ~ ~ p=1.000 n=6+0
Total Time 95.57s (± 0.44%) 0s ~ ~ ~ p=1.000 n=6+0
self-build-src - node (v18.15.0, x64)
Errors 0 0 ~ ~ ~ p=1.000 n=6
Symbols 1,215,031 1,215,064 +33 (+ 0.00%) ~ ~ p=0.001 n=6
Types 257,343 257,352 +9 (+ 0.00%) ~ ~ p=0.001 n=6
Memory used 2,322,975k (± 0.05%) 2,322,813k (± 0.04%) ~ 2,322,132k 2,324,351k p=0.471 n=6
Parse Time 7.58s (± 0.59%) 7.50s (± 0.71%) -0.07s (- 0.95%) 7.44s 7.59s p=0.031 n=6
Bind Time 2.73s (± 0.43%) 2.73s (± 0.64%) ~ 2.70s 2.75s p=0.683 n=6
Check Time 49.53s (± 0.79%) 49.47s (± 0.49%) ~ 49.19s 49.79s p=0.936 n=6
Emit Time 4.04s (± 2.22%) 4.11s (± 2.03%) ~ 3.96s 4.20s p=0.230 n=6
Total Time 63.90s (± 0.66%) 63.82s (± 0.35%) ~ 63.57s 64.14s p=0.575 n=6
self-build-src-public-api - node (v18.15.0, x64)
Errors 0 0 ~ ~ ~ p=1.000 n=6
Symbols 1,215,031 1,215,064 +33 (+ 0.00%) ~ ~ p=0.001 n=6
Types 257,343 257,352 +9 (+ 0.00%) ~ ~ p=0.001 n=6
Memory used 2,398,236k (± 0.04%) 2,397,698k (± 0.03%) ~ 2,396,914k 2,398,915k p=0.298 n=6
Parse Time 7.84s (± 0.82%) 7.82s (± 0.81%) ~ 7.73s 7.88s p=0.630 n=6
Bind Time 2.45s (± 0.66%) 2.45s (± 0.95%) ~ 2.43s 2.49s p=0.936 n=6
Check Time 50.11s (± 0.32%) 50.19s (± 0.37%) ~ 49.94s 50.47s p=0.575 n=6
Emit Time 3.96s (± 3.27%) 3.95s (± 2.67%) ~ 3.83s 4.08s p=0.630 n=6
Total Time 64.37s (± 0.39%) 64.43s (± 0.44%) ~ 64.19s 64.86s p=0.470 n=6
self-compiler - node (v18.15.0, x64)
Errors 0 0 ~ ~ ~ p=1.000 n=6
Symbols 256,191 256,213 +22 (+ 0.01%) ~ ~ p=0.001 n=6
Types 103,624 103,633 +9 (+ 0.01%) ~ ~ p=0.001 n=6
Memory used 423,993k (± 0.00%) 424,063k (± 0.01%) +70k (+ 0.02%) 424,020k 424,097k p=0.008 n=6
Parse Time 4.33s (± 0.68%) 4.35s (± 0.72%) ~ 4.30s 4.39s p=0.625 n=6
Bind Time 1.60s (± 0.97%) 1.59s (± 1.38%) ~ 1.56s 1.62s p=0.276 n=6
Check Time 22.44s (± 0.34%) 22.40s (± 0.23%) ~ 22.30s 22.44s p=0.687 n=6
Emit Time 1.75s (± 1.67%) 1.76s (± 1.31%) ~ 1.73s 1.80s p=0.374 n=6
Total Time 30.12s (± 0.31%) 30.09s (± 0.24%) ~ 29.99s 30.17s p=0.687 n=6
ts-pre-modules - node (v18.15.0, x64)
Errors 35 35 ~ ~ ~ p=1.000 n=6
Symbols 224,824 224,824 ~ ~ ~ p=1.000 n=6
Types 93,390 93,390 ~ ~ ~ p=1.000 n=6
Memory used 369,292k (± 0.02%) 369,290k (± 0.02%) ~ 369,197k 369,399k p=1.000 n=6
Parse Time 2.96s (± 0.75%) 2.95s (± 1.37%) ~ 2.89s 2.99s p=0.629 n=6
Bind Time 1.59s (± 1.34%) 1.59s (± 0.65%) ~ 1.58s 1.60s p=0.560 n=6
Check Time 15.71s (± 0.26%) 15.73s (± 0.26%) ~ 15.68s 15.77s p=0.418 n=6
Emit Time 0.00s 0.00s ~ ~ ~ p=1.000 n=6
Total Time 20.26s (± 0.27%) 20.27s (± 0.24%) ~ 20.22s 20.36s p=0.628 n=6
vscode - node (v18.15.0, x64)
Errors 18 0 ~ ~ ~ p=1.000 n=6+0
Symbols 2,795,223 0 ~ ~ ~ p=1.000 n=6+0
Types 949,808 0 ~ ~ ~ p=1.000 n=6+0
Memory used 2,923,552k (± 0.00%) 0k ~ ~ ~ p=1.000 n=6+0
Parse Time 16.79s (± 0.76%) 0s ~ ~ ~ p=1.000 n=6+0
Bind Time 5.05s (± 2.32%) 0s ~ ~ ~ p=1.000 n=6+0
Check Time 88.08s (± 0.42%) 0s ~ ~ ~ p=1.000 n=6+0
Emit Time 26.84s (± 8.43%) 0s ~ ~ ~ p=1.000 n=6+0
Total Time 136.76s (± 1.29%) 0s ~ ~ ~ p=1.000 n=6+0
webpack - node (v18.15.0, x64)
Errors 0 0 ~ ~ ~ p=1.000 n=6
Symbols 265,853 265,853 ~ ~ ~ p=1.000 n=6
Types 108,438 108,438 ~ ~ ~ p=1.000 n=6
Memory used 410,229k (± 0.02%) 410,204k (± 0.01%) ~ 410,165k 410,276k p=0.936 n=6
Parse Time 3.27s (± 0.53%) 3.25s (± 0.82%) ~ 3.21s 3.28s p=0.081 n=6
Bind Time 1.41s (± 0.45%) 1.40s (± 1.05%) ~ 1.37s 1.41s p=0.081 n=6
Check Time 14.44s (± 0.36%) 14.45s (± 0.45%) ~ 14.38s 14.55s p=0.936 n=6
Emit Time 0.00s 0.00s ~ ~ ~ p=1.000 n=6
Total Time 19.13s (± 0.33%) 19.10s (± 0.33%) ~ 19.03s 19.17s p=0.468 n=6
xstate-main - node (v18.15.0, x64)
Errors 0 0 ~ ~ ~ p=1.000 n=6
Symbols 523,981 523,981 ~ ~ ~ p=1.000 n=6
Types 178,708 178,708 ~ ~ ~ p=1.000 n=6
Memory used 461,150k (± 0.01%) 461,219k (± 0.02%) ~ 461,136k 461,334k p=0.199 n=6
Parse Time 2.69s (± 1.08%) 2.69s (± 0.80%) ~ 2.66s 2.72s p=1.000 n=6
Bind Time 0.99s 0.99s ~ ~ ~ p=1.000 n=6
Check Time 15.41s (± 0.24%) 15.42s (± 0.33%) ~ 15.36s 15.51s p=0.872 n=6
Emit Time 0.00s 0.00s ~ ~ ~ p=1.000 n=6
Total Time 19.09s (± 0.23%) 19.11s (± 0.28%) ~ 19.06s 19.21s p=0.374 n=6
System info unknown
Hosts
  • node (v18.15.0, x64)
Scenarios
  • Compiler-Unions - node (v18.15.0, x64)
  • angular-1 - node (v18.15.0, x64)
  • mui-docs - node (v18.15.0, x64)
  • self-build-src - node (v18.15.0, x64)
  • self-build-src-public-api - node (v18.15.0, x64)
  • self-compiler - node (v18.15.0, x64)
  • ts-pre-modules - node (v18.15.0, x64)
  • vscode - node (v18.15.0, x64)
  • webpack - node (v18.15.0, x64)
  • xstate-main - node (v18.15.0, x64)
Benchmark Name Iterations
Current pr 6
Baseline baseline 6

tsserver

Comparison Report - baseline..pr
Metric baseline pr Delta Best Worst p-value
Compiler-UnionsTSServer - node (v18.15.0, x64)
Req 1 - updateOpen 2,831ms (± 1.09%) 2,819ms (± 0.87%) ~ 2,789ms 2,841ms p=0.575 n=6
Req 2 - geterr 6,137ms (± 0.65%) 6,128ms (± 0.65%) ~ 6,085ms 6,199ms p=0.936 n=6
Req 3 - references 368ms (± 9.69%) 356ms (± 2.04%) ~ 346ms 363ms p=0.809 n=6
Req 4 - navto 286ms (± 6.31%) 296ms (± 9.43%) ~ 276ms 339ms p=0.864 n=6
Req 5 - completionInfo count 1,357 1,357 ~ ~ ~ p=1.000 n=6
Req 5 - completionInfo 95ms (± 3.08%) 108ms (± 9.92%) ~ 94ms 116ms p=0.060 n=6
CompilerTSServer - node (v18.15.0, x64)
Req 1 - updateOpen 2,497ms (± 1.85%) 2,502ms (± 1.38%) ~ 2,474ms 2,568ms p=0.575 n=6
Req 2 - geterr 3,834ms (± 0.11%) 3,839ms (± 0.26%) ~ 3,828ms 3,849ms p=0.571 n=6
Req 3 - references 300ms (± 0.40%) 300ms (± 0.47%) ~ 298ms 302ms p=0.743 n=6
Req 4 - navto 228ms (± 0.43%) 229ms (± 0.24%) ~ 228ms 229ms p=0.662 n=6
Req 5 - completionInfo count 1,519 1,519 ~ ~ ~ p=1.000 n=6
Req 5 - completionInfo 77ms (± 7.40%) 79ms (± 7.70%) ~ 72ms 85ms p=0.360 n=6
xstate-main-1-tsserver - node (v18.15.0, x64)
Req 1 - updateOpen 5,195ms (± 0.31%) 5,179ms (± 0.20%) ~ 5,167ms 5,196ms p=0.063 n=6
Req 2 - geterr 1,126ms (± 0.05%) 1,130ms (± 0.70%) ~ 1,124ms 1,145ms p=0.803 n=6
Req 3 - references 85ms (± 1.21%) 87ms (± 3.85%) ~ 84ms 93ms p=0.784 n=6
Req 4 - navto 448ms (± 0.09%) 452ms (± 1.11%) ~ 446ms 458ms p=0.199 n=6
Req 5 - completionInfo count 3,413 3,413 ~ ~ ~ p=1.000 n=6
Req 5 - completionInfo 837ms (± 0.74%) 853ms (± 2.68%) ~ 834ms 890ms p=0.172 n=6
System info unknown
Hosts
  • node (v18.15.0, x64)
Scenarios
  • CompilerTSServer - node (v18.15.0, x64)
  • Compiler-UnionsTSServer - node (v18.15.0, x64)
  • xstate-main-1-tsserver - node (v18.15.0, x64)
Benchmark Name Iterations
Current pr 6
Baseline baseline 6

startup

Comparison Report - baseline..pr
Metric baseline pr Delta Best Worst p-value
tsc-startup - node (v18.15.0, x64)
Execution time 157.37ms (± 0.15%) 157.57ms (± 0.17%) +0.21ms (+ 0.13%) 156.42ms 161.28ms p=0.000 n=600
tsserver-startup - node (v18.15.0, x64)
Execution time 239.31ms (± 0.13%) 239.39ms (± 0.14%) +0.09ms (+ 0.04%) 238.00ms 244.45ms p=0.009 n=600
tsserverlibrary-startup - node (v18.15.0, x64)
Execution time 235.53ms (± 0.15%) 235.63ms (± 0.13%) +0.10ms (+ 0.04%) 234.21ms 237.79ms p=0.001 n=600
typescript-startup - node (v18.15.0, x64)
Execution time 287.18ms (± 0.29%) 286.97ms (± 0.27%) -0.21ms (- 0.07%) 279.74ms 292.17ms p=0.000 n=600
System info unknown
Hosts
  • node (v18.15.0, x64)
Scenarios
  • tsc-startup - node (v18.15.0, x64)
  • tsserver-startup - node (v18.15.0, x64)
  • tsserverlibrary-startup - node (v18.15.0, x64)
  • typescript-startup - node (v18.15.0, x64)
Benchmark Name Iterations
Current pr 6
Baseline baseline 6

Developer Information:

Download Benchmarks

@rbuckton
Copy link
Member Author

Hm, crash on the DT code, it looks. Definitely relevant.

Not source mapped, so that's less than helpful :/

@jakebailey
Copy link
Member

jakebailey commented Apr 24, 2024

The assert is from:

Debug.assert(scanner.reScanSlashToken(/*reportErrors*/ true) === SyntaxKind.RegularExpressionLiteral);

In: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/codemirror/test/addon/mode/simple.ts

$ NODE_OPTIONS=--enable-source-maps pnpm dtslint --localTs ~/work/TypeScript/built/local types codemirror
dtslint@0.2.20
Error: Debug Failure. False expression.
Occurred while linting /home/jabaile/work/DefinitelyTyped/types/codemirror/test/addon/mode/simple.ts:1
Rule: "@definitelytyped/expect"
    at checkGrammarRegularExpressionLiteral (/home/jabaile/work/TypeScript/src/compiler/checker.ts:31382:23)
    at <anonymous> (/home/jabaile/work/TypeScript/src/compiler/checker.ts:31397:37)
    at addLazyDiagnostic (/home/jabaile/work/TypeScript/src/compiler/checker.ts:47223:35)
    at checkRegularExpressionLiteral (/home/jabaile/work/TypeScript/src/compiler/checker.ts:31397:13)
    at checkExpressionWorker (/home/jabaile/work/TypeScript/src/compiler/checker.ts:39712:24)
    at checkExpression (/home/jabaile/work/TypeScript/src/compiler/checker.ts:39621:36)
    at checkExpressionForMutableLocation (/home/jabaile/work/TypeScript/src/compiler/checker.ts:39357:22)
    at checkPropertyAssignment (/home/jabaile/work/TypeScript/src/compiler/checker.ts:39371:16)
    at checkObjectLiteral (/home/jabaile/work/TypeScript/src/compiler/checker.ts:31658:80)
    at checkExpressionWorker (/home/jabaile/work/TypeScript/src/compiler/checker.ts:39716:24)

Repro instructions are:

$ git clone --filter=blob:none https://github.com/DefinitelyTyped/DefinitelyTyped.git
$ cd DefinitelyTyped
$ pnpm i --filter . --filter '...{./types/codemirror}...'
$ NODE_OPTIONS=--enable-source-maps pnpm dtslint --localTs ~/work/TypeScript/built/local types codemirror

@rbuckton
Copy link
Member Author

The assert is from: [...]

I was able to repro it locally. I was lamenting the lack of source maps, but I should have tagged the assert with an appropriate message anyways.

The assert was overaggressive since we can also rescan /= as well. I removed it since the assert on the next line would catch any discrepancy anyways.

@rbuckton
Copy link
Member Author

@typescript-bot run dt

@typescript-bot
Copy link
Collaborator

typescript-bot commented Apr 24, 2024

Starting jobs; this comment will be updated as builds start and complete.

Command Status Results
run dt ✅ Started ✅ Results

@typescript-bot
Copy link
Collaborator

Hey @rbuckton, the results of running the DT tests are ready.

Everything looks the same!

You can check the log here.

@rbuckton
Copy link
Member Author

@weswigham, @DanielRosenwasser, any other comments?


function checkRegularExpressionLiteral(node: RegularExpressionLiteral) {
const nodeLinks = getNodeLinks(node);
if (!nodeLinks.grammarChecked) {
Copy link
Member

Choose a reason for hiding this comment

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

I think you can actually reuse NodeCheckFlags.TypeChecked for this, if you'd like. It's how we do similar marking for getter/setter pairs, and nodes with a checkNodeDeferred component.

@DanielRosenwasser
Copy link
Member

The assert was overaggressive since we can also rescan /= as well. I removed it since the assert on the next line would catch any discrepancy anyways.

Does that mean we have no test with /= in it?

@rbuckton
Copy link
Member Author

The assert was overaggressive since we can also rescan /= as well. I removed it since the assert on the next line would catch any discrepancy anyways.

Does that mean we have no test with /= in it?

Apparently not. I'll add one.

@DanielRosenwasser
Copy link
Member

@weswigham why does it have to be a lazy diagnostic though? Where does the order-checking impact anything else here?

@weswigham
Copy link
Member

why does it have to be a lazy diagnostic though? Where does the order-checking impact anything else here?

It allows us to completely skip the rescan when, eg, requesting completions in the file.

@rbuckton
Copy link
Member Author

why does it have to be a lazy diagnostic though? Where does the order-checking impact anything else here?

It allows us to completely skip the rescan when, eg, requesting completions in the file.

We will eventually want to always perform the scan if we want to leverage information like group names or capture group counting to infer stronger types for RegExpExecArray, but it makes sense to defer it for now.

@DanielRosenwasser
Copy link
Member

Okay, I guess don't have a strong opinion about it. It does feel a little premature since ideally a scan should be fast enough, but it's no big deal for now. Are we good with merging?

@rbuckton
Copy link
Member Author

Okay, I guess don't have a strong opinion about it. It does feel a little premature since ideally a scan should be fast enough, but it's no big deal for now. Are we good with merging?

I'm mostly waiting on the macos tests to catch up, but they're lagging about 4hrs behind right now. Nothing in this PR should be OS dependent, so I'm fine with merging if we don't want to wait.

@rbuckton rbuckton merged commit e28ad99 into main Apr 24, 2024
25 checks passed
@rbuckton rbuckton deleted the regexp-syntax-check-annexB branch April 24, 2024 23:16
@graphemecluster
Copy link
Contributor

After this PR, these lines no longer work and might happen to break something as the early exit causes the token span and value to be different depending on reportErrors, thus should be removed. (I did it in #58289)

graphemecluster added a commit to graphemecluster/TypeScript that referenced this pull request Apr 25, 2024
The change is no longer necessary since it’s moved to `checker.ts` in microsoft#58295.

The partially reverts microsoft@1a5228d.
@nostalic nostalic mentioned this pull request May 10, 2024
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants