Top-level await reparse keeps statements it already consumed when it reaches the end of the file
維護者通常 1 天內回覆
評估
- 難度
- 4/5
- 預估耗時
- 1-2 天
- 新手友好度
- 25/100
- Issue 類型
- 缺陷
- 描述清晰度
- 描述清楚
- 活躍度
- 停滯
- 技術堆疊
- go, typescript
- 領域
- compilers
研究方向
Start with the Go parser’s reparseTopLevelAwait path and inspect how it copies original statements after reparsing advances to the end of the file. Reproduce the overlapping statement positions with the provided input and check the regression test in linked pull request #64993; done means no copied statement starts before the end of its preceding statement.
由索引模型根據 Issue 內容生成。
描述
🔎 Search Terms
top-level await, reparse, reparseTopLevelAwait, overlapping statements, parse tree, sibling
🕗 Version & Regression Information
- TypeScript 7 at
main4a4b24d5dc96d148641ec6a39c4f5bbf023cbb2f (the Go parser). - TypeScript 6.0.3 also keeps overlapping statements for this input: its
ExpressionStatement [26, 28)starts before the statement before it ends at 37.
⏯ Playground Link
Not applicable: the problem is in the parse tree's node positions.
💻 Code
export {}; await + f(const 0 await !x
🙁 Actual behavior
The source file's statements are ExportDeclaration [0, 10), ExpressionStatement [10, 37) and ExpressionStatement [36, 37). The last one starts before the previous one ends: x is parsed twice, once inside the reparsed await + f(...) statement and once as a statement of its own.
In a module, reparseTopLevelAwait reparses the statements that may contain await in an await context, and a reparsed statement can read past its span. When the reparse reaches the end of the file, the original statements after the last span it advanced to are still copied into the new statement list.
🙂 Expected behavior
No statement starts before the end of the statement before it: once the reparse reaches the end of the file, no original statement is left to copy.
Additional information about the issue
Found by fuzzing the parser of a fork of this repository with a sibling-order invariant (each node starts at or after the end of its previous sibling). A fix with a regression test is in #64993.
This report was drafted with Claude Code (Claude Opus 5.5).
- 主要語言
- Go
- 星號
- 112k
- 分支
- 15.4k
- 平均合併
- 3 天 6 小時
- 30 天內合併 PR
- 136
環境準備
在瀏覽器裡用你自己的 GitHub 帳號啟動這個專案的開發容器。
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
microsoft/TypeScript 的其他 Issue
-
Native API: formatDiagnosticsWithColorAndContext drops related information without a file location未關閉
難度 2/5 1-3 小時 新手友好度 75/100
microsoft/TypeScript#65087 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 75/100
microsoft/TypeScript#65083 ·
維護者通常 1 天內回覆
-
TS7 LSP: documentHighlight returns nothing when the file path contains '@'可能重新可做 關聯的 PR 已關閉且未合併。 未關閉Bug
難度 2/5 1-3 小時 新手友好度 78/100
microsoft/TypeScript#64758 ·
維護者通常 1 天內回覆
-
Language server (tsc --lsp) exits with code 1 after `shutdown` and `exit`可能已有人在做 @rajnish-verma-22172 於 12 天前認領。 未關閉Bug
難度 2/5 1-3 小時 新手友好度 76/100
microsoft/TypeScript#64742 · 1 則留言 ·
維護者通常 1 天內回覆
-
Class names `eval` and `arguments` are not reported as invalid strict mode bindings可能已有人在做 @dmety 於 25 天前認領。 未關閉Bug
難度 2/5 1-3 小時 新手友好度 68/100
microsoft/TypeScript#64661 ·
維護者通常 1 天內回覆
查看 microsoft/TypeScript 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 72/100
apache/arrow-swift#209 ·
維護者通常 1 天內回覆
-
orchestrator: NFS-cache "cache path is not set" WARN logged on every build/launch instead of once可能已有人在做 關聯的 PR 仍在進行中或已合併。 未關閉
難度 2/5 1-3 小時 新手友好度 72/100
維護者通常 2 天內回覆
-
難度 1/5 1-3 小時 新手友好度 65/100
influxdata/telegraf#20031 ·
維護者通常 1 天內回覆
-
pkg/registry/file no longer builds for GOOS=windows: unguarded syscall.Stat_t in qualified_resource_migration.go可能已有人在做 @AnshulPatil2005 今天認領。 未關閉
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 74/100
OneBusAway/maglev#1914 ·
維護者通常 2 天內回覆