Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

A regex literal that starts a statement is parsed as division, and the formatter removes the parentheses that prevent it

未關閉
#8,688 0 則留言 1 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
68/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
ocaml
領域
compilers, tooling

研究方向

Start with compiler/syntax/src/res_core.ml, especially parse_binary_expr, and reproduce the issue with npx rescript format src/A.res followed by npx rescript build. Trace how a regex literal at the start of a statement is parsed and how its parentheses are formatted. Done means the shown source remains parseable after formatting and the build succeeds.

由索引模型根據 Issue 內容生成。

描述

Thank you for filing! Check list:

  • Is it a bug? Usage questions should often be asked in the forum instead.
  • Concise, focused, friendly issue title & description.
  • A minimal, reproducible example.
  • OS and browser versions, if relevant.
  • Is it already fixed in master? Instructions

A regex literal at the start of a statement, on the line after another statement, is parsed as a division that continues the previous line, so the file does not parse.
rescript format produces exactly this form from code that parses: it removes the parentheses around the literal.

Snippet

src/A.res:

let f = s => {
  let t = s
  (/a/)->RegExp.test(t)
}
npx rescript format src/A.res
cat src/A.res
npx rescript build

Actual

let f = s => {
  let t = s
  /a/->RegExp.test(t)
}
Cleaned 0/0
Error in check:

  Syntax error!
  /path/to/check/src/A.res:3:6-7

  1 │ let f = s => {
  2 │   let t = s
  3 │   /a/->RegExp.test(t)
  4 │ }
  5 │ 

  Did you forget to write an expression here?


Incremental build failed. Error:   Could not parse Source Files

The formatted form fails the same way when written by hand, and so does a regex literal after an expression statement (Console.log(s)) or after a top-level let.

The formatter gives the same result for the other spellings that parse:

  • ; at the end of the line before the literal (let t = s;) is removed;
  • on 12.3.1, %re("/a/")->RegExp.test(t) becomes /a/->RegExp.test(t).

These spellings parse and keep their form after formatting:

  • the literal as the first statement of the block;
  • the literal as a call argument: RegExp.test(/a/, t);
  • the literal bound to a name first: let r = /a/.

Expected

The file parses: / at the start of a statement starts a regex literal.
If that is not possible, the formatter keeps the parentheses (or the ;) in front of such a literal.

Possible cause: in parse_binary_expr (compiler/syntax/src/res_core.ml), Minus | MinusDot | LessThan | Percent on a new line with no whitespace after it is not taken as a binary operator.
Forwardslash has no such case, so / on a new line always continues the expression on the line before.

Worked in ReScript 11

ReScript 11.1.4 has no regex literals, and its formatter keeps %re:

let f = s => {
  let t = s
  %re("/a/")->Js.Re.test_(t)
}

The same commands print the file unchanged and build it:

let f = s => {
  let t = s
  %re("/a/")->Js.Re.test_(t)
}
>>>> Start compiling
Dependency Finished
rescript: [1/3] src/A.ast
rescript: [2/3] src/A.d
rescript: [3/3] src/A.cmj
>>>> Finish compiling 19 mseconds

Environment

  • ReScript 12.3.1, 13.0.0-alpha.6, and master 58c6c89 (from pkg.pr.new, reports 13.0.0-alpha.7): the same result on all three.
  • Node.js 24.9.0
  • Linux x86_64

Context

We hit it when rescript format 12.3.1 rewrote %re("/^[0-9\.,+-]*$/")->RegExp.test(str) ? Some(str) : None, which came right after a let line in a block.

Workaround

Pass the literal as an argument (RegExp.test(/a/, t)) or bind it with let first.

主要語言
OCaml
星號
7.5k
分支
485
平均合併
1 天 6 小時
30 天內合併 PR
52

環境準備

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

rescript-lang/rescript 的其他 Issue

查看 rescript-lang/rescript 的全部 Issue

相似的 Issue

更多 Compilers Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。