Skip to content

Record written arrow arity before external lowering - #8563

Open
cristianoc wants to merge 1 commit into
codex/harden-parsetree0-bridgefrom
codex/parsed-arrow-arity
Open

Record written arrow arity before external lowering#8563
cristianoc wants to merge 1 commit into
codex/harden-parsetree0-bridgefrom
codex/parsed-arrow-arity

Conversation

@cristianoc

Copy link
Copy Markdown
Collaborator

Summary

  • record an arrow type's written parameter count directly in the parsetree, including phantom @as(...) _ parameters on externals
  • remove the parser-side decrement and matching printer compensation
  • give bare labeled arrow types the same arity as their parenthesized spelling

Rationale

External lowering already removes phantom parameters and rebuilds the function type with its effective call arity. Encoding that lowered arity in the parser made the surface parsetree context-dependent and required the printer to reverse the adjustment. Keeping the written arity makes the parser representation consistent while preserving generated JavaScript.

Bare labeled arrow types previously printed like their parenthesized equivalent but carried different arity metadata and therefore did not unify with it.

Validation

  • make test-syntax
  • make test
  • parser snapshots cover the bare labeled spelling
  • existing external fixtures retain byte-identical generated JavaScript

External arrow parsing used to subtract labelled phantom @as(...) _ parameters from the head arity, while the printer added them back. No downstream consumer needs that parser-level encoding: external lowering removes phantom parameters and rebuilds the type with the effective call arity.

Record the written parameter count in the parsetree instead and remove the parser and printer compensation. Also assign arity 1 to bare labelled arrow types so they agree with their parenthesized spelling.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Cristiano Calcagno <cristianoc@users.noreply.github.com>
@cristianoc
cristianoc force-pushed the codex/parsed-arrow-arity branch 2 times, most recently from 86a3008 to e45b706 Compare August 18, 2026 12:56
@cristianoc
cristianoc marked this pull request as ready for review August 18, 2026 13:01
@cristianoc
cristianoc requested a review from cknitt August 18, 2026 13:02

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e45b706218

ℹ️ 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".

arrow, exactly like its parenthesized form [(~x: t) => u]; it must
carry the same arity or the two spellings produce types that print
identically but do not unify. *)
Ast_helper.Typ.arrow ~loc ~arity:(Some 1) {attrs; lbl; typ} return_type

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P1 Badge Add behavioral coverage for labeled-arrow unification

Add a lambda/end-to-end regression that typechecks or calls through equivalent ~x: int => string and (~x: int) => string annotations. The changed snapshots only verify the parsed arity metadata, so the user-facing claim that these spellings now unify could regress in later compiler layers while every added test continues to pass; repository guidance explicitly requires syntax, lambda, and end-to-end coverage for compiler changes.

AGENTS.md reference: AGENTS.md:L39-L41

Useful? React with 👍 / 👎.

@codecov

codecov Bot commented Aug 18, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 85.71429% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 75.58%. Comparing base (9043bbb) to head (e45b706).

Files with missing lines Patch % Lines
compiler/syntax/src/res_core.ml 85.71% 1 Missing ⚠️
Additional details and impacted files
@@                        Coverage Diff                         @@
##           codex/harden-parsetree0-bridge    #8563      +/-   ##
==================================================================
- Coverage                           75.59%   75.58%   -0.01%     
==================================================================
  Files                                 476      476              
  Lines                               62759    62745      -14     
==================================================================
- Hits                                47443    47428      -15     
- Misses                              15316    15317       +1     
Files with missing lines Coverage Δ
compiler/syntax/src/res_parsetree_viewer.ml 90.48% <ø> (-0.13%) ⬇️
compiler/syntax/src/res_core.ml 91.48% <85.71%> (-0.05%) ⬇️
🚀 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

pkg-pr-new Bot commented Aug 18, 2026

Copy link
Copy Markdown

Open in StackBlitz

rescript

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

@rescript/darwin-arm64

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

@rescript/darwin-x64

npm i https://pkg.pr.new/@rescript/darwin-x64@8563

@rescript/linux-arm64

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

@rescript/linux-x64

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

@rescript/runtime

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

@rescript/win32-x64

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

commit: e45b706

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant