report error messages #2

New issue

Open

opened 2026-03-19 15:44:30 +01:00 by christian · 0 comments

christian commented

2026-03-19 15:44:30 +01:00

Owner

Currenly it's easy to make our AST parser fail while the type checker succeeds, e.g.

[%css [ Pseudo.hover [] ] ]

[%css
  [ Pseudo.first_line
      [ Pseudo.hover [ color (rgb 255 0 0) ] ]
  ]
]

If our AST parser fails, it expands to a Rule.t list instead of a class name which leads to very confusing compile errors when the user tries to use the "class name".

While the first example could be prevented by allowing empty lists (empty rulesets are a warning, not an error in CSS), the second example is more difficult to work around. The problem is that the Pseudo_element constructor of the Rule.t type allows definitions like the above, but they would actually produce invalid CSS (see "Cannot represent pseudo-elements"). This is why for pseudo-elements, our AST parser only accepts nested definitions, not nested pseudo-classes or pseudo-elements.

The question is: Can we report error messages to the user, that make it clear where exactly the parsing failed? Maybe the Merlin_helpers module can help?

Currenly it's easy to make our AST parser fail while the type checker succeeds, e.g. ```ocaml [%css [ Pseudo.hover [] ] ] ``` or ```ocaml [%css [ Pseudo.first_line [ Pseudo.hover [ color (rgb 255 0 0) ] ] ] ] ``` If our AST parser fails, it expands to a ``Rule.t list`` instead of a class name which leads to very confusing compile errors when the user tries to use the "class name". While the first example could be prevented by allowing empty lists (empty rulesets are a warning, not an error in CSS), the second example is more difficult to work around. The problem is that the ``Pseudo_element`` constructor of the ``Rule.t`` type allows definitions like the above, but they would actually produce invalid CSS (see ["Cannot represent pseudo-elements"](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/Nesting_selector#cannot_represent_pseudo-elements)). This is why for pseudo-elements, our AST parser only accepts nested definitions, not nested pseudo-classes or pseudo-elements. The question is: Can we report error messages to the user, that make it clear where exactly the parsing failed? Maybe the [Merlin_helpers](https://ocaml-ppx.github.io/ppxlib/ppxlib/Ppxlib/Merlin_helpers/index.html) module can help?

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

christian/ppx_stylesheet#2

No description provided.

Rows
Columns