Repository navigation
Parser: an attribute or doc comment in front of a {... spread type changes how it is read #9122
Description
A type body starting with {... can be a record spread or an object spread. Without a prefix, the parser reads it as a record unless a quoted field follows. With an attribute or a doc comment in front, it takes a different path, so the prefix changes what the declaration means or makes it a syntax error.
Checked on master at 85f31fb with bsc -bs-no-builtin-ppx -only-parse -dparsetree:
type t = … |
no prefix | @attr |
/** d */ |
|---|---|---|---|
{...base, y: int} |
record | syntax error | record |
{...base} |
record | object type | record |
{...base, "y": int} |
object type | object type | syntax error |
The same holds after private, e.g. type t = private @attr {...base, y: int} is a syntax error.
Cause: after an attribute, the lookahead in res_core.ml treats {... as the start of a type expression (object type); after a doc comment, the record path is taken unconditionally. #9115 (for #9106) keeps both behaviours as they are, so nothing master accepts changes there.
Expected: the prefix doesn't matter, and {... is classified as without one. That fixes both syntax errors, but it also turns @attr {...base} from an object type into a record, which changes code that compiles today, so it needs a changelog entry.
🤖 Generated with Claude Code
Activity