Formatter prints @res.doc on a function parameter as a doc comment that does not parse
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 68/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- ocaml
- Domain
- compilers
Research direction
Start by tracing bsc -format from the formatter path that prints @res.doc on function parameters; compare it with how @ocaml.doc and @ns.doc are preserved, and inspect the parser around parameter doc comments. The issue permits either keeping the attribute form in formatter output or accepting the comment in the parser. Done means the shown input formats to output that parses successfully when formatted again.
Written by the indexing model from the issue text.
Description
The formatter prints a @res.doc attribute on a function parameter as a doc comment in front of the parameter, and the parser rejects that output.
let f = (@res.doc("The runner") run: string) => run
bsc -format prints:
let f = (
/**The runner*/
run: string,
) => run
Formatting that output again fails:
Syntax error!
2 │ /**The runner*/
3 │ run: string,
I'm not sure what to parse here when looking at "DocComment The runner".
So formatting turns a file that compiles into one that doesn't. @ocaml.doc/@ns.doc on a parameter have been formatted unchanged, because the printer prints only res.doc as a doc comment. If #8992 lands, @res.doc is the only doc attribute left, so writing it by hand on a parameter hits this. genType's tests/gentype_tests/typescript-react-example/src/Comments.res keeps @ocaml.doc on two parameters for this reason.
Either the printer keeps the attribute form for parameters, or the parser accepts a doc comment before a parameter.
Found while working on #8978.
🤖 Generated with Claude Code
- Dominant language
- OCaml
- Stars
- 7.5k
- Forks
- 483
- Avg merge
- 19h 35m
- Merged PRs (30d)
- 208
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rescript-lang/rescript
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
rescript-lang/rescript#9037 ·
Maintainers usually reply within 1 day
-
Per-constructor @unboxed is not compared across interfaces or coercionsPossibly taken @cknitt claimed this today. Open
Difficulty 4/5 3-5 days Newbie friendliness 25/100
rescript-lang/rescript#9038 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
rescript-lang/rescript#9006 · 1 reaction ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 70/100
rescript-lang/rescript#8997 ·
Maintainers usually reply within 1 day
-
@notUndefined in an interface is not checked against the implementationPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 4/5 3-5 days Newbie friendliness 35/100
rescript-lang/rescript#8964 · 1 comment ·
Maintainers usually reply within 1 day
All issues in rescript-lang/rescript
Similar issues
-
area:codegen backend:cuda backend:hip bug direction:input
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
CrossGL/crosstl#3061 · 1 comment ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
build
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
AOMediaCodec/SVT-AV1#2500 ·
-
SIGSEGV in symex on __builtin_constant_p of a void expressionPossibly taken A pull request linked to this issue is open or already merged. Openbug goto-symex
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day