[cknitt]

Some Windows editors save files with a UTF-8 byte order mark, and both bsc and bsc -format rejected such files with one "Not sure what to do with this character" error per BOM byte. Separately, a \r without a following \n ended a // comment but did not count as a line break, so let x = 1 // c\rlet y = 2 failed with "Consecutive statements on a line must be separated by ';' or a newline".

Stacked on #9116 (it touches Res_multi_printer.print and the analysis format command that #9116 reworks); the base is fix-9100-format-line-endings-strings.

The fix:

• The scanner starts after a leading byte order mark (Res_scanner.byte_order_mark). The first line's pos_bol is the byte offset after the mark, so columns don't count it and pos_cnum remains a byte offset into the source for ASCII text, which the parser relies on (e.g. is_binary_op).
• The scanner ends a line at a CR not followed by LF, like editors and JavaScript; CRLF still ends a line once, at its LF. A regex literal now also ends (as unterminated) at a CR.
• Code frames agree with the scanner: they start the first line after a byte order mark and treat a lone CR as a line break (replaced by LF in place, so byte offsets stay valid). Without this, the highlight on a BOM file's first line was shifted by three bytes, and a CR-only file showed as one line.
• bsc -format and the analysis format command keep a byte order mark.

Tests in tests/syntax_tests/res_test.ml: formatting keeps a BOM (LF and CRLF files) and is idempotent; formatting with a lone CR after a // comment, and a CR-only file; line and column of statements after lone CRs, after \r\r, \n\r, CRLF, and after a BOM; a regex literal with a lone CR is rejected; code frames for a BOM file and a CR-only file. Each assertion group fails with the corresponding part of the fix removed.

Open questions:

• A CR-only file is formatted with LF line breaks, since Keep line breaks inside literals when formatting #9116 picks CRLF when the first line break is CRLF and LF otherwise. Recognising a lone CR as the newline there would keep such files as they are, but CR-only files are rare enough that I left it.
• res_parser -print res (the syntax test tool) does not keep the BOM; only bsc -format and the editor's format command do.

Fixes #9108

🤖 Generated with Claude Code

https://claude.ai/code/session_01Kbf3gGkPma9LAZimuQjnrP

[github-actions]

Changelog

🐛 Bug fix

• Accept source files that start with a UTF-8 byte order mark, keeping it when formatting, and end a line at a carriage return without a line feed.

Semantic Diff

1 commit · Full page

Skip a UTF-8 byte order mark and end a line at a lone CR

_{467af56 · cknitt + Claude · Oct 28, 2026, 15:56 UTC}

Why

Some Windows editors write a byte order mark, and bsc and bsc -format rejected it byte by byte. A CR without an LF ended a // comment but did not start a new line, so the next statement counted as on the same line. The scanner now starts after a byte order mark and ends a line at a CR not followed by LF, as editors and JavaScript do; code frames show lines the same way, and the formatter keeps the byte order mark.

Diagnostic removed (byte order mark)

\xEF\xBB\xBFlet x = 1

diagnostic

-Syntax error!
-A.res:1:1
-
-Not sure what to do with this character: "\239".
-… the same for "\187" and "\191"
+none

Diagnostic removed (lone CR)

let x = 1 // c\rlet y = 2

diagnostic

-Syntax error!
-B.res:1:10-18
-
-Consecutive statements on a line must be separated by ';' or a newline
+none

Format modified (lone CR)

let x = 1 // c\rlet y = 2

text · Before

Syntax error

rescript · After

let x = 1 // c
let y = 2

Fixes #9108

Review

• Why convert a CR-only file to LF when formatting? The formatter writes CRLF when the first line break is CRLF and LF otherwise (Keep line breaks inside literals when formatting #9116); CR-only files are rare enough not to get their own newline.

[codecov]

Codecov Report

❌ Patch coverage is 83.33333% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.47%. Comparing base (9de0dae) to head (467af56).

Files with missing lines	Patch %	Lines
analysis/src/commands.ml	0.00%	3 Missing ⚠️
compiler/ml/code_frame.ml	87.50%	1 Missing ⚠️

Additional details and impacted files

@@                          Coverage Diff                          @@
##           fix-9100-format-line-endings-strings    #9120   +/-   ##
=====================================================================
  Coverage                                 81.47%   81.47%           
=====================================================================
  Files                                       460      460           
  Lines                                     64680    64701   +21     
=====================================================================
+ Hits                                      52696    52714   +18     
- Misses                                    11984    11987    +3     

Files with missing lines	Coverage Δ
compiler/syntax/src/res_multi_printer.ml	80.00% <100.00%> (+1.42%)	⬆️
compiler/syntax/src/res_scanner.ml	91.65% <100.00%> (+0.30%)	⬆️
compiler/ml/code_frame.ml	94.16% <87.50%> (-0.42%)	⬇️
analysis/src/commands.ml	62.06% <0.00%> (-1.32%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pkg-pr-new]

Open in StackBlitz

rescript

npm i https://pkg.pr.new/rescript@9120

@rescript/belt

npm i https://pkg.pr.new/@rescript/belt@9120

@rescript/darwin-arm64

npm i https://pkg.pr.new/@rescript/darwin-arm64@9120

@rescript/linux-arm64

npm i https://pkg.pr.new/@rescript/linux-arm64@9120

@rescript/linux-x64

npm i https://pkg.pr.new/@rescript/linux-x64@9120

@rescript/runtime

npm i https://pkg.pr.new/@rescript/runtime@9120

@rescript/win32-x64

npm i https://pkg.pr.new/@rescript/win32-x64@9120

commit: 467af56

[cknitt]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-28T16:42:59.277470Z	be57a8b	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. What shall we delve into next?

Reviewed commit: be57a8b7a4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[cristianoc]

Reviewed BOM handling, lone-CR scanning, diagnostic frames and regression tests against the #9116 base. No blocking issues found. CI, including BOM/lone-CR and syntax tests, passes; not rerun locally.