You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 83f5eea
Browse filesBrowse the repository at this point in the historyBrowse files
Keep attributes in front of a record or open type representation (#8919)
* Keep attributes in front of a record or open type representation
Why:
The parser accepts attributes between `=` and a record declaration or
`..` (since #7787) but threw them away, so a PPX such as sury never saw
`@s.strict`. They now go on the type declaration, after its leading
attributes, and the formatter prints them in front of `type`. The
attributed path also passes the inline-record context on, so nested
record types inside such a record parse.
AST modified (attribute before a record representation):
Example:
@Schema
type t = @s.strict {email: string}
Before (parse):
type_declaration "t"
attribute "schema"
[]
ptype_params =
[]
ptype_cstrs =
[]
ptype_kind =
Ptype_record
…
After (parse):
type_declaration "t"
attribute "schema"
[]
attribute "s.strict"
[]
ptype_params =
[]
ptype_cstrs =
[]
ptype_kind =
Ptype_record
…
Diagnostic removed (nested record after an attribute):
Example:
type u = @attr {x: {y: int}}
Before (diagnostic):
An inline record type declaration is only allowed in a variant
constructor's declaration or nested inside of a record type declaration
Format modified (attribute before a record representation):
Example:
@Schema
type t = @s.strict {email: string}
type u = @attr {x: {y: int}}
Before (rescript):
@Schema
type t = {email: string}
// type u: syntax error
After (rescript):
@Schema@s.strict type t = {email: string}
@attr type u = {x: {y: int}}
Review: Why the declaration and not an error? The issue asks for the
attribute to reach the PPX, and the declaration is the only parsetree node
a record or open type kind has. An attribute in front of a constructor
still attaches to that constructor.
Fixes#7814
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kr4cjoUi2f5VpMvE6wT9bo
Signed-off-by: Christoph Knittel <ck@cca.io>
* Keep a doc comment in front of a record or open type representation
Why:
Only a doc comment after an attribute reached the declaration; one
directly after `=` was parsed as the start of a constructor list and
failed on `{` or `..`. It now goes through the same lookahead as an
attribute: in front of `{` or `..` it attaches to the type declaration,
in front of a constructor it still attaches to that constructor.
AST modified (doc comment before a record representation):
Example:
type t = /** doc */ {x: int}
Before (diagnostic):
At this point, I'm looking for an uppercased name like `Array` or `Math`
After (parse):
type_declaration "t"
attribute "res.doc"
[
structure_item
Pstr_eval
expression
Pexp_constant PConst_string (source=" doc ", semantic=" doc ")
]
ptype_params =
[]
ptype_cstrs =
[]
ptype_kind =
Ptype_record
…
Format modified (doc comment before a record or open representation):
Example:
type t = /** doc */ {x: int}
type u = /** doc */ ..
After (rescript):
/** doc */
type t = {x: int}
/** doc */
type u = ..
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kr4cjoUi2f5VpMvE6wT9bo
Signed-off-by: Christoph Knittel <ck@cca.io>
* Share the type representation arm for a doc comment after `=`
The doc comment arm differed from the `Bar | DotDot` arm only in passing
the inline-record context, which the other two never reach, so one arm
serves all three. Behaviour is unchanged; the existing parser and printer
fixtures cover it, so no test is added.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kr4cjoUi2f5VpMvE6wT9bo
Signed-off-by: Christoph Knittel <ck@cca.io>
---------
Signed-off-by: Christoph Knittel <ck@cca.io>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
- Keep attributes and doc comments written in front of a record or `..` type representation, attaching them to the type declaration instead of dropping them.
0 commit comments