Regression: comment on labeled argument formatted away

[cknitt]

The comment in

@@uncurried

let f = (
  // comment
  ~a,
) => a

is preserved when formatting with 10.1.3, but gets removed when formatting with master:

@@uncurried

let f = (~a) => a

[cristianoc]

Works on master.

[cknitt]

Confirmed, this is working again now.

[cknitt]

@cristianoc Actually the problem is still there, but it happens in uncurried mode only.

[cristianoc]

So that position is something that does not correspond to anything in the parse tree. There's going to be some workaround to represent a comment in that position, which does not like the transformation to uncurried function definition.

Something perhaps even more important, is that one cannot put doc comments in that position (syntax error). CC @zth who had been asking about this last thing.
Generically speaking, since there's no way to store doc comments on arguments, they need to be stored on the function. So e.g. (a,b) => ... has 2 functions in the parse tree, and that's where the doc comments would be stored.

As a separate thought, I was wondering whether normal comments should be treated exactly like doc comments. That would limit the positions comments can be places, but would imply the comments are in the AST so the outcome would be much more predictable.
While this is probably possible for /* ... */ comments, I'm not sure at all about line comments // ... which perhaps need a special treatment anyway.

[cristianoc]

Had a chat with Intelligentia A. about the topic. Turns out there's something one could do and has not been explored:

Context

This discussion revolves around the ReScript language, which uses a handwritten parser and is bound to the existing OCaml AST definitions for compatibility reasons. The challenge is to find a way to represent comments in the AST, particularly when it comes to pretty printing and doc comments, while preserving compatibility with other tools.

Proposed Solution: Extended OCaml AST

A proposed solution is to create a pure extension of the OCaml AST, where nodes only become bigger to store additional information, such as comments. This extended AST would be written to disk, maintaining compatibility with other tools.

Benefits

• Allows storing comment information directly within the AST.
• Enables improved comment handling during pretty printing.
• Maintains compatibility with existing tools that rely on the OCaml AST.

Potential Dangers

• Assumes that OCaml's marshaling mechanism is forward-compatible and can handle the extended AST.
• Assumes that existing tools can gracefully ignore any unknown data in the extended AST.
• Performance impact due to larger nodes.

Testing

The extended AST has been tested to ensure that the OCaml serialization and deserialization mechanisms can handle the extended AST gracefully, and the tools can ignore the extra information.

Conclusion

Given the successful test results, the extended OCaml AST approach seems to be a viable solution for representing comments in the ReScript language while preserving compatibility with other tools. Thorough testing with various ReScript programs and different tools and libraries is crucial to ensure the robustness and compatibility of this solution. Engaging with the ReScript and OCaml communities can provide additional insights and feedback to further refine the approach.

[zth]

This seems to be a parser issue only, because attributes attach fine to the arguments (using ns.doc, with res.doc it's autoformated to a docstring, which right now is a syntax error):

let someFunc = (
  @ns.doc("Fine arg.") ~arg1: bool,
  @ns.doc("Fine arg 2.") ~arg2: option<string>=?,
  @ns.doc("Fine arg 3.") arg3: string,
) => {
  ignore(arg1)
  ignore(arg2)
  ignore(arg3)
}

Haven't checked where the attributes end up though, but I assume it must be on the function. And haven't checked whether they "make it" to the typed tree. But they should if they end up attached to the function.

I'm very interested in supporting this use case. Both for the WIP doc extraction, and for leveraging it in the editor for showing documentation.

[cristianoc]

[
  structure_item
    ...
      <def>
        pattern
          Ppat_var "someFunc"
        expression
          Pexp_fun
          Labelled "arg1"
          None
          pattern
            attribute "res.namedArgLoc"
              []
            attribute "ns.doc"
              [
                ...
                expression
                  Pexp_constant PConst_string ("Fine arg.", Some "*j")
              ]
            Ppat_constraint
            pattern
              Ppat_var "arg1"
            core_type
              Ptyp_constr "bool"
              []
          expression
            Pexp_fun
            Optional "arg2"
            None
            pattern
              attribute "res.namedArgLoc"
                []
              attribute "ns.doc"
                [
                  ...
                  expression
                    Pexp_constant PConst_string ("Fine arg 2.", Some "*j")
                ]
              Ppat_constraint
              pattern
                Ppat_var "arg2"
              core_type
                Ptyp_constr "option"
                [
                  core_type
                    Ptyp_constr "string"
                    []
                ]
            expression
              Pexp_fun
              Nolabel
              None
              pattern
                attribute "ns.doc"
                  [
                    ...
                    expression
                      Pexp_constant PConst_string ("Fine arg 3.", Some "*j")
                  ]
                Ppat_constraint
                pattern
                  Ppat_var "arg3"
                core_type
                  Ptyp_constr "string"
                  []
              expression
                ...
]

[cristianoc]

[cristianoc]

So yes ^ it's on the function.

[zth]

Can you see whether it ends up in the typed tree?

[cristianoc]

Can you see whether it ends up in the typed tree?

I know it does. But I can double check.