Skip to content

Allow skipping leading pipe in definitions of variants with attribute on leading constructor #7782

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

Merged
merged 2 commits into from
Aug 22, 2025

Conversation

zth
Copy link
Member

@zth zth commented Aug 21, 2025

Fixes #7578 by simply allowing it instead.

@shulhi GPT5 figured most of this out, but to me it looks reasonable and good. WDYT?

@zth zth requested review from shulhi and Copilot August 21, 2025 20:58
Copy link

pkg-pr-new bot commented Aug 21, 2025

Open in StackBlitz

rescript

npm i https://pkg.pr.new/rescript-lang/rescript@7782

@rescript/darwin-arm64

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

@rescript/darwin-x64

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

@rescript/linux-arm64

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

@rescript/linux-x64

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

@rescript/win32-x64

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

commit: 1e43c40

Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

@shulhi
Copy link
Member

shulhi commented Aug 22, 2025

LGTM! This is even better than just fixing the error message.

@zth zth merged commit 09903f9 into master Aug 22, 2025
27 checks passed
@zth zth deleted the allow-skip-pipe-variant-parsing branch August 22, 2025 04:03
match state.Parser.token with
| Dot -> false
| _ -> true)
| DotDotDot | Bar | DocComment _ -> true
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should this be DotDot as above or DotDotDot as here?

@cristianoc
Copy link
Collaborator

cristianoc commented Aug 22, 2025

Some low priority observation. We don't really have use cases so far, but the parser is more strict than needed.


Short answer: besides the “leading-constructor” case that PR unblocks, the current logic still treats any @attribute at the start of a type representation as “this must be a variant, which blocks a few other, sensible openings.

Here are the concrete places you’ll want to allow an initial @attribute, but which are currently funneled into the variant path:

  1. @attribute before a record representation
    Example that ought to work:
    type t = @attr { x: int }
    Today, parse_type_representation maps At directly to Ptype_variant, so this is misclassified (it never looks ahead to see the {). The fix mirrors your new lookahead: consume attributes, then if the next token is {, choose Ptype_record; otherwise fall back to the variant branch. ([GitHub]1)

  2. @attribute before an open/extensible variant marker (..)
    Example that ought to work:
    type t = @attr .. | A
    Your new lookahead after At checks for DotDotDot (ellipsis) but an open type uses DotDot (..), so @attr .. is currently misrouted (treated as not-a-variant and then fails as a manifest). Change the check to include DotDot (and probably not DotDotDot here). ([GitHub]1)

  3. @attribute followed by a doc comment that precedes a non-variant representation
    If you ever want to allow type t = @attr /**doc for the record*/ { x:int } (or even before ..), the new lookahead classifies any DocComment after attributes as “variant”, so these would be misparsed. If that placement should be legal, the lookahead needs to skip doc comments, too, before deciding. (Right now, DocComment is a hard signal for “variant”.) ([GitHub]1)

What to change (surgically)

  • In parse_type_representation: replace the bare | … | DocComment _ | At -> Ptype_variant … with an At branch that peeks past attributes; choose Ptype_record if the next token is {, choose the variant branch if it’s |, Uident (not followed by .), .., or a doc-comment before a constructor, else error. ([GitHub]1)
  • In the At lookahead you added to parse_type_equation_and_representation: recognize DotDot (not DotDotDot) as variant; optionally skip DocComment tokens when they precede { or ... ([GitHub]1)

If you make those two tweaks, you’ll cover:

  • type t = @attr One … ✅ (already covered)
  • type t = @attr { … }
  • type t = @attr .. | A
  • (Optionally) type t = @attr /**doc*/ { … } and type t = @attr /**doc*/ .. | …

All of the above are blocked today because At is treated as “variant opener” without peeking at what follows, and because the lookahead after At doesn’t recognize ... ([GitHub]1)

@zth
Copy link
Member Author

zth commented Aug 22, 2025

Some low priority observation. We don't really have use cases so far, but the parser is more strict than needed.

Short answer: besides the “leading-constructor” case that PR unblocks, the current logic still treats any @attribute at the start of a type representation as “this must be a variant, which blocks a few other, sensible openings.

Here are the concrete places you’ll want to allow an initial @attribute, but which are currently funneled into the variant path:

  1. @attribute before a record representation
    Example that ought to work:
    type t = @attr { x: int }
    Today, parse_type_representation maps At directly to Ptype_variant, so this is misclassified (it never looks ahead to see the {). The fix mirrors your new lookahead: consume attributes, then if the next token is {, choose Ptype_record; otherwise fall back to the variant branch. ([GitHub]1)
  2. @attribute before an open/extensible variant marker (..)
    Example that ought to work:
    type t = @attr .. | A
    Your new lookahead after At checks for DotDotDot (ellipsis) but an open type uses DotDot (..), so @attr .. is currently misrouted (treated as not-a-variant and then fails as a manifest). Change the check to include DotDot (and probably not DotDotDot here). ([GitHub]1)
  3. @attribute followed by a doc comment that precedes a non-variant representation
    If you ever want to allow type t = @attr /**doc for the record*/ { x:int } (or even before ..), the new lookahead classifies any DocComment after attributes as “variant”, so these would be misparsed. If that placement should be legal, the lookahead needs to skip doc comments, too, before deciding. (Right now, DocComment is a hard signal for “variant”.) ([GitHub]1)

What to change (surgically)

  • In parse_type_representation: replace the bare | … | DocComment _ | At -> Ptype_variant … with an At branch that peeks past attributes; choose Ptype_record if the next token is {, choose the variant branch if it’s |, Uident (not followed by .), .., or a doc-comment before a constructor, else error. ([GitHub]1)
  • In the At lookahead you added to parse_type_equation_and_representation: recognize DotDot (not DotDotDot) as variant; optionally skip DocComment tokens when they precede { or ... ([GitHub]1)

If you make those two tweaks, you’ll cover:

  • type t = @attr One … ✅ (already covered)
  • type t = @attr { … }
  • type t = @attr .. | A
  • (Optionally) type t = @attr /**doc*/ { … } and type t = @attr /**doc*/ .. | …

All of the above are blocked today because At is treated as “variant opener” without peeking at what follows, and because the lookahead after At doesn’t recognize ... ([GitHub]1)

Nice! This definitely sounds worth fixing. I'll see if I can get to it soon.

@cristianoc
Copy link
Collaborator

Haven't checked that this code change works, but seems at least directionally OK at a glance.


Awesome — here’s a minimal, surgical patch to compiler/syntax/src/res_core.ml that:

  • fixes the DotDotDotDotDot typo,
  • lets an initial @attribute precede records ({ ... }),
  • lets an initial @attribute precede open/extensible variants (..),
  • and (optionally) skips doc comments between the attributes and the deciding token.
diff --git a/compiler/syntax/src/res_core.ml b/compiler/syntax/src/res_core.ml
--- a/compiler/syntax/src/res_core.ml
+++ b/compiler/syntax/src/res_core.ml
@@ -5044,11 +5044,33 @@ and parse_type_representation ?current_type_name_path ?inline_types_context p =
   in
   let kind =
     match p.Parser.token with
-    | Bar | Uident _ | DocComment _ | At ->
-        Parsetree.Ptype_variant (parse_type_constructor_declarations p)
+    | Bar | Uident _ | DocComment _ ->
+        Parsetree.Ptype_variant (parse_type_constructor_declarations p)
+    | At ->
+        (* Attributes can prefix either a variant (constructor list) or a record.
+           Peek past attributes (and any doc comments) to decide. *)
+        let is_record_after_attrs =
+          Parser.lookahead p (fun state ->
+            ignore (parse_attributes state);
+            let rec skip_docs () =
+              match state.Parser.token with
+              | DocComment _ -> Parser.next state; skip_docs ()
+              | _ -> ()
+            in
+            skip_docs ();
+            match state.Parser.token with
+            | Lbrace -> true
+            | _ -> false)
+        in
+        if is_record_after_attrs
+        then Parsetree.Ptype_record
+        else Parsetree.Ptype_variant (parse_type_constructor_declarations p)
     | Lbrace ->
         Parsetree.Ptype_record
     | _ ->
       (* unchanged ... *)
@@ -5602,6 +5624,38 @@ and parse_type_equation_and_representation ?current_type_name_path
     | Bar | DotDot | DocComment _ ->
       let priv, kind = parse_type_representation p in
       (None, priv, kind)
-    | At -> (
-      (* Attribute can start a variant constructor or a type manifest.
-         Look ahead past attributes; if a constructor-like token follows (Uident not immediately
-         followed by a Dot, or DotDotDot/Bar/DocComment), treat as variant; otherwise manifest *)
-      let is_variant_after_attrs =
-        Parser.lookahead p (fun state ->
-          ignore (parse_attributes state);
-          match state.Parser.token with
-          | Uident _ -> (
-              Parser.next state;
-              match state.Parser.token with
-              | Dot -> false
-              | _ -> true)
-          | DotDotDot | Bar | DocComment _ -> true
-          | _ -> false)
-      in
-      if is_variant_after_attrs then
-        let priv, kind = parse_type_representation p in
-        (None, priv, kind)
-      else
-        let manifest = Some (parse_typ_expr p) in
-        match p.Parser.token with
-        | Equal ->
-            Parser.next p;
-            let priv, kind =
-              parse_type_representation ?current_type_name_path
-                ?inline_types_context p
-            in
-            (manifest, priv, kind)
-        | _ -> (manifest, Public, Parsetree.Ptype_abstract))
+    | At -> (
+        (* Attributes can start a representation (variant/record/open variant) or a manifest.
+           Look ahead past attributes (and doc comments). If what follows looks like a
+           representation, parse it; otherwise parse a manifest. *)
+        let is_representation_after_attrs =
+          Parser.lookahead p (fun state ->
+            ignore (parse_attributes state);
+            (* allow doc comments between attributes and the representation token *)
+            let rec skip_docs () =
+              match state.Parser.token with
+              | DocComment _ -> Parser.next state; skip_docs ()
+              | _ -> ()
+            in
+            skip_docs ();
+            match state.Parser.token with
+            | Lbrace -> true                  (* record after attributes *)
+            | Bar -> true                     (* variant constructor list *)
+            | DotDot -> true                  (* extensible variant ".." *)
+            | Uident _ ->                     (* constructor vs module-qualified manifest *)
+                Parser.next state;
+                (match state.Parser.token with
+                 | Dot -> false               (* M.t  => manifest *)
+                 | _ -> true)                 (* Uident starting a constructor *)
+            | DocComment _ -> true            (* treated as representation; variant path handles it *)
+            | _ -> false)
+        in
+        if is_representation_after_attrs then
+          let priv, kind = parse_type_representation p in
+          (None, priv, kind)
+        else
+          let manifest = Some (parse_typ_expr p) in
+          match p.Parser.token with
+          | Equal ->
+              Parser.next p;
+              let priv, kind =
+                parse_type_representation ?current_type_name_path ?inline_types_context p
+              in
+              (manifest, priv, kind)
+          | _ -> (manifest, Public, Parsetree.Ptype_abstract))
     | _ -> (
       let manifest = Some (parse_typ_expr p) in
       match p.Parser.token with

Notes

  • The At branch in parse_type_representation now peeks to select record vs variant.
  • The At branch in parse_type_equation_and_representation now peeks for record {, open variant .. (using DotDot), |, or a constructor (Uident not followed by .), and (optionally) skips a run of DocComment tokens before deciding.
  • Everything else falls back to parsing a manifest exactly as before.

This patch applies cleanly on top of the code added in PR #7782 (commit 1e43c40). ([github.com]1)

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.

Improve error message when variant constructor is not prepended with pipe
3 participants