Improve unclear error messages surfaced by super_errors fixtures by JonoPrest · Pull Request #2 · JonoPrest/rescript-compiler

JonoPrest · 2026-06-02T04:26:38Z

Follow-up to the super_errors fixture coverage work. Improves error and warning messages that were unclear, including the ones cknitt flagged on rescript-lang#8432. Message text only, no behaviour changes.

Non-function application: "It has type" instead of the contradictory "The function has type".
@return(*_to_opt): plain wording that shows the option syntax.
@int / @string @as payloads, and the int/string/json @as payload: name the attribute and the expected literal.
Conflicting attributes: list the mutually exclusive set (@string, @int, @ignore, @unwrap).
Render @ correctly in FFI attribute messages (they rendered %@ literally).
@this simple-pattern: fix the rendering and grammar.

One commit per message. super_errors fixtures updated to match.

* Convert to snake case * Update CHANGELOG.md * fix reactive_test * rename gen_type to gentype * Fix suspicious names

Saying "The function has type" right after "it's not a function" was contradictory. Use "It has type" instead.

The old message was grammatically broken ("expect return type to be syntax wise `_ option` for safety") and rendered `%@return` literally. State the requirement plainly and show the option syntax.

"expect int literal" was terse and contextless. Name the attribute and show the expected form.

@int

"conflicting attributes" did not say which attributes conflict. List the mutually-exclusive set (@string, @int, @ignore, @unwrap).

@unwrap

These messages used "%@" where they meant "@" (e.g. "%@string", "%@unwrap", "conflicts with %@Val"). pp_print_string emits it literally, so users saw "%@". Use "@" so the attribute name reads correctly.

@this

Fix the "%@this" rendering and the broken grammar ("expect its pattern variable to be simple form"). State what is required and why.

@as

Capitalize and use a full sentence instead of "expect string literal " (trailing space). Kept generic since it is shared by @as payloads and @@directive.

Replace "expect int, string literal or json literal {json|text here|json}" with a plain sentence.

@this

Verified against the raise sites: - @this (ast_uncurry_gen.ml): the self parameter must satisfy is_single_variable_pattern_conservative, i.e. a plain variable or `_`. A constant pattern also fails and `_` is allowed, so "not a destructured pattern" was imprecise. State the requirement positively. - @return (ast_external_process.ml): `nullable` and `null_undefined_to_opt` trigger this too, not just `*_to_opt` directives, so describe the option requirement generically rather than naming the directive shape.

Replace the OCaml-style `let rec' quoting with `let rec`.

Warnings 52 and 57 pointed users to "manual section 8.5" of the OCaml manual, which is irrelevant to ReScript. Also add a space after the comma when listing ambiguous or-pattern variables.

List the supported directives instead of the terse "Not supported return directive".

Duplicated_bs_as also fires for record fields (e.g. inline records) and polymorphic-variant tags, not just variant cases, so the message should not say "a variant case".

@inline

The misplaced-@inline warning hardcoded "inline1"/"inline2" as the attribute name, leaking an internal distinction; the user wrote @inline. Use the real attribute name.

@as

Warnings 47/53/54 referred to attributes as "inline" / 'inline'; ReScript messages elsewhere use the @-prefixed form (@as, @deriving, ...). Use @inline etc. for consistency.

@int

Conflict_attributes now carries the list of attributes involved, so the message reports all of them (e.g. "@string, @int, @unwrap") instead of the full set of every possible attribute.

…s error

…error

"is not allowed in programs" was vague; type variable names cannot start with an underscore.

"expects 1 argument(s), but is here applied to 2 argument(s)" -> proper singular/plural and "is given".

- first-class module instead of "packed module" - explain that a cross-module GADT constructor needs its module prefix - explain the existential-in-pattern error and point to switch

Quote the name like the other polished messages (and the same message's zero-argument branch already does).

Errors are sentence-case; "unsupported predicates" and the consecutive- statements syntax error started lowercase.

@unwrap

- Add a fixture for a non-generic type applied to arguments (covers the zero-arity branch of the type-arity-mismatch message, and the plural case). - Add an @ignore/@unwrap conflict fixture (covers those attr_name arms). - Drop the unreachable `Nothing` arm from attr_name by typing the collected list to the four real tags and coercing the single-tag result.

JonoPrest force-pushed the jono/improve-error-messages branch 7 times, most recently from df15a5d to 4b6a19c Compare June 2, 2026 11:52

aspeddro and others added 23 commits June 3, 2026 19:27

Convert to snake case (rescript-lang#8456)

77a6290

* Convert to snake case * Update CHANGELOG.md * fix reactive_test * rename gen_type to gentype * Fix suspicious names

Improve non-function application error wording

eaa08ac

Saying "The function has type" right after "it's not a function" was contradictory. Use "It has type" instead.

Improve @return(*_to_opt) error message

ea4f1aa

The old message was grammatically broken ("expect return type to be syntax wise `_ option` for safety") and rendered `%@return` literally. State the requirement plainly and show the option syntax.

Improve @int variant @as payload error message

924df9f

"expect int literal" was terse and contextless. Name the attribute and show the expected form.

Improve conflicting-attributes error message

98e2ced

"conflicting attributes" did not say which attributes conflict. List the mutually-exclusive set (@string, @int, @ignore, @unwrap).

Render @ correctly in FFI attribute error messages

9941a5c

These messages used "%@" where they meant "@" (e.g. "%@string", "%@unwrap", "conflicts with %@Val"). pp_print_string emits it literally, so users saw "%@". Use "@" so the attribute name reads correctly.

Improve @this simple-pattern error message

d4d6fe3

Fix the "%@this" rendering and the broken grammar ("expect its pattern variable to be simple form"). State what is required and why.

Tidy the "expected a string literal" error message

0d86cba

Capitalize and use a full sentence instead of "expect string literal " (trailing space). Kept generic since it is shared by @as payloads and @@directive.

Tidy the @as int/string/json literal error message

ada53da

Replace "expect int, string literal or json literal {json|text here|json}" with a plain sentence.

Fix subject-verb agreement in type-params-not-supported error

0ae8105

Fix list grammar in @as variant annotation error

25e71c3

Use ReScript-style quoting for let rec in letrec errors

2834153

Replace the OCaml-style `let rec' quoting with `let rec`.

Drop OCaml-manual references from warning messages

9863419

Warnings 52 and 57 pointed users to "manual section 8.5" of the OCaml manual, which is irrelevant to ReScript. Also add a space after the comma when listing ambiguous or-pattern variables.

Improve duplicate @as annotation error wording

9f649e2

Improve duplicate @deriving attribute error wording

2c756dc

Improve unsupported @return directive error message

5097a90

List the supported directives instead of the terse "Not supported return directive".

Make duplicate @as message context-neutral

478c552

Duplicated_bs_as also fires for record fields (e.g. inline records) and polymorphic-variant tags, not just variant cases, so the message should not say "a variant case".

Report the real attribute name in misplaced @inline warning

93d326a

The misplaced-@inline warning hardcoded "inline1"/"inline2" as the attribute name, leaking an internal distinction; the user wrote @inline. Use the real attribute name.

Use @-prefixed attribute names in attribute warnings

ef95ef9

Warnings 47/53/54 referred to attributes as "inline" / 'inline'; ReScript messages elsewhere use the @-prefixed form (@as, @deriving, ...). Use @inline etc. for consistency.

Name the conflicting attributes in the conflict error

0bd1528

Conflict_attributes now carries the list of attributes involved, so the message reports all of them (e.g. "@string, @int, @unwrap") instead of the full set of every possible attribute.

Use 'switch' instead of OCaml ''match' expression' in no-value-clause…

df62d4c

…s error

Say 'pattern' instead of OCaml 'matching' in multiply-bound-variable …

efe7c2f

…error

JonoPrest added 8 commits June 4, 2026 08:06

Clarify the fragile-pattern-in-toplevel error wording

d15fc11

State the rule in the invalid type-variable-name error

ef9c443

"is not allowed in programs" was vague; type variable names cannot start with an underscore.

Fix pluralization and phrasing in type-arity-mismatch error

c001778

"expects 1 argument(s), but is here applied to 2 argument(s)" -> proper singular/plural and "is given".

Clarify packed-module / GADT-pattern / existential error messages

b7f5c45

- first-class module instead of "packed module" - explain that a cross-module GADT constructor needs its module prefix - explain the existential-in-pattern error and point to switch

Backtick the type-constructor name in type-arity-mismatch error

8670c1e

Quote the name like the other polished messages (and the same message's zero-argument branch already does).

Add changelog entry for error/warning message improvements

c2cffb9

Capitalize two lowercase error messages for consistency

fa243b1

Errors are sentence-case; "unsupported predicates" and the consecutive- statements syntax error started lowercase.

JonoPrest force-pushed the jono/improve-error-messages branch from 386d81b to 76fd535 Compare June 4, 2026 08:09

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improve unclear error messages surfaced by super_errors fixtures#2

Improve unclear error messages surfaced by super_errors fixtures#2
JonoPrest wants to merge 31 commits into
masterfrom
jono/improve-error-messages

JonoPrest commented Jun 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

JonoPrest commented Jun 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants