Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Formatter: five cases where comments and doc comments are placed wrongly

Chiusa
  • Qualcosa non va?
#9,107 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #9119 di @cknitt — integrata

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
ocaml
Ambito
compilers

Direzione di ricerca

Start with the formatter cases described in the issue and inspect parameters_should_hug in compiler/syntax/src/res_parsetree_viewer.ml for the first case. Reproduce each of the five examples and trace the comment handling and formatting paths involved. Done means all five format correctly and remain stable when formatted again, with case 4 preserving the AST; an open pull request is already linked.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Found by a bug hunt over the 16 commits from eb087382 to cd641cbc.

All five are stable when formatted again. The fourth changes the AST, and the others change only the layout.

  1. A doc comment on a single hugged parameter is printed with a line break and no indent:
    let f = (/** r */ {x, y}) => x prints as let f = (/** r */ followed by {x, y}) => x at column 0. The same happens for [a], (a, b) and (). parameters_should_hug checks the parameter's attrs but not pat.ppat_attributes, where the doc comment is stored. This input is accepted since #9055.
  2. A trailing line comment after a parenthesized switch/if operand moves into the block, followed by a blank line:
    switch (x) // c1 then { | 1 => 2 | _ => 3 } prints as switch x {, then // c1, a blank line and | 1 => 2. Without the parentheses (#9061) the comment stays with the operand.
  3. A comment before a list tail spread moves after the dots:
    list{1, /* c */ ...xs} prints as list{1, .../* c */ xs}. Arrays keep it in place.
  4. Doc comments are printed before an attribute that precedes them, which changes the attribute order in the AST:
    type u = /** d1 */ @a /** d2 */ {x: int} prints /** d1 */, /** d2 */, then @a type u = {x: int}.
  5. A file that contains only a line comment gets an extra trailing newline: // c\n formats as // c\n\n.

Cases 2, 3 and 5 reproduce at b123b7c3. That revision rejects the inputs of 1 and 4.

🤖 Generated with Claude Code

Lingua principale
OCaml
Stelle
7.5k
Fork
484
Merge medio
21h 9m
PR unite (30g)
255

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rescript-lang/rescript

Tutte le issue di rescript-lang/rescript

Issue simili

Altre issue su Compilers

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.