Aligning implementation/specification error codes - phase 3 by Roman-Manevich · Pull Request #1989 · herd/herdtools7

Roman-Manevich · 2026-09-04T11:27:35Z

Distinguish lexical and parse failures

Lexer-detected invalid symbols now use UnknownSymbol and report BE_LE, preserving suggested replacements, while the remaining CannotParse errors report BE_PE.

Classify global-initialization exceptions

Exceptions escaping global initialization now report DE_UE, and build_genv in asl.spec converts the corresponding throwing result to DynamicError(DE_UE).

Classify asserted-type-conversion failures

Failed asserted type conversions now use ATCFailure, reporting DE_TAF during dynamic evaluation and TE_SEF during static evaluation as specified by asl.spec.

Classify repeated tuple-field writes

Repeated fields in tuple assignments now report TE_IAD, matching the specification's use of check_no_duplicates rather than the rework PR's disputed BE_PE mapping.

Distinguish call and tuple arity failures

Static call arity failures now report TE_BC through BadCallArity, while tuple arity failures report TE_UT through BadTupleArity; unchecked runtime arity failures remain uncoded.

hrutvik · 2026-09-04T15:10:56Z

          "array@ length@ expression@ %a@ has@ negative@ length:@ %i." pp_expr
          e_length length
-    | MultipleWrites id -> pp_err Parse "multiple@ writes@ to@ %S." id
+    | MultipleWrites id -> pp_err Typing "multiple@ writes@ to@ %S." id


This error is reported during AST building (desugaring specifically) - why is it a typing error?

This is a bit subtle. AssignableExpressions.tex defines the (AST) desugaring rule by calling check_no_duplicates, which returns a type error. We can roll back to Parse but then there's a discrepancy between the implementation and documentation.
Alternatively, we could change the spec (say, by creating a dedicated duplicates check) so that raises a build error.

The spec needs changing.

Reverted Typing back to Parse.
Changed the spec to compare the cardinality of the set of fields with the length of the list and have it emit BE_PE if they differ.

hrutvik · 2026-09-04T15:19:51Z

  | BadArity of error_handling_time * identifier * int * int
+  | BadCallArity of { name : identifier; expected : int; provided : int }
+  | BadTupleArity of { expected : int; actual : int }
  | BadParameterArity of error_handling_time * version * identifier * int * int


What are the status of BadArity and BadParameterArity after the new Bad{Call,Tuple}Arity? For example, is BadArity an V0-only error, and only used with Dynamic? If so, we should remove error_handling_time from BadArity.

BadArity is used in both ASLv0 and ASLv1 contexts and its error_handling_time depends on the configuration passed to Make in Interpreter.ml so both static/dynamic are possible. The situation is similar with BadParameterArity.

Uses of BadArity seem to be:

In Interpreter.ml for:

incorrect argument/parameter arity for a subprogram call

protected_multi_assign

run_typed

in Native.ml for primitives

From a brief look, these all seem to be for untyped specifications - I believe ASL1 type-checking would catch all of these before interpretation. Am I missing something?

answered offline.

hrutvik · 2026-09-04T15:36:28Z

        fatal_from ~loc
-        @@ Error.BadArity
-             (Static, name, List.length callee.args, List.length args1)
+        @@ Error.BadCallArity


This is an ASL0-only error site - does it need to change?

As long as we support ASL0, this seems like an improvement in terms of the error code and diagnostic message.

ASL0 does not have error codes

Still, this is consistent with the same check for ASLv1. I don't see how this hurts.

HadrienRenaud · 2026-09-07T08:13:16Z

         else
-           fatal_from e1 env (Error.MismatchType (B.debug_value v, [ t.desc ])))
+           fatal_from e1 env
+             (Error.ATCFailure (C.error_handling_time, B.debug_value v, t.desc)))


Maybe we should have something a bit more flexible than debug_value, ideally a formatter

Probably not for this PR.

HadrienRenaud · 2026-09-07T08:16:23Z

@@ -42,6 +42,8 @@ type error_desc =
      found_call_type : subprogram_type;
    }
  | BadArity of error_handling_time * identifier * int * int


What is BadArity used for then? Maybe add a little comment to explain this?

How about

An arity mismatch detected during evaluation: a subprogram or primitive receives the wrong number of arguments, a tuple assignment receives the wrong number of values from a subprogram call, or an entry point returns the wrong number of values.

?

I like it, what about adding quickly at the start that this should not happen if type-checking worked correctly?

HadrienRenaud · 2026-09-07T08:17:56Z



-  ASL Lexical error (BE_LE): Unknown symbol.
+  ASL Lexical error (BE_LE): Unknown symbol "".


Oh that's ugly, should we create an issue about this?

HadrienRenaud

This looks ok to me, but please double check with Hrutvik that he's happy with it

HadrienRenaud · 2026-09-08T09:01:03Z

+  | BadCallArity of { name : identifier; expected : int; provided : int }
+  | BadTupleArity of { expected : int; actual : int }


There's a naming mismatch between those 2 declaration: should we use provided or actual?

HadrienRenaud · 2026-09-08T09:03:57Z

+      (** An arity mismatch detected during evaluation: a subprogram or
+          primitive receives the wrong number of arguments, a tuple assignment
+          receives the wrong number of values from a subprogram call, or an
+          entry point returns the wrong number of values. *)


This is nice, just a tiny edit:

Suggested change

(** An arity mismatch detected during evaluation: a subprogram or

primitive receives the wrong number of arguments, a tuple assignment

receives the wrong number of values from a subprogram call, or an

entry point returns the wrong number of values. *)

(** [BadArity (time, name, expected, provided)] is raised when there is

an arity mismatch detected during evaluation when it should have been

detected at type-checking: a subprogram or

primitive receives the wrong number of arguments, a tuple assignment

receives the wrong number of values from a subprogram call, or an

entry point returns the wrong number of values. *)

Roman-Manevich changed the title ~~Aligning implementation/specification error codes - phase 2~~ Aligning implementation/specification error codes - phase 3 Sep 4, 2026

Roman-Manevich marked this pull request as ready for review September 4, 2026 11:42

Roman-Manevich requested review from HadrienRenaud and hrutvik September 4, 2026 11:42

Roman-Manevich changed the base branch from master to asl-error-codes-phase-2 September 4, 2026 11:42

Roman-Manevich force-pushed the asl-error-codes-phase-3 branch 2 times, most recently from 71be2cd to 79d0133 Compare September 4, 2026 14:14

hrutvik reviewed Sep 4, 2026

View reviewed changes

Roman-Manevich force-pushed the asl-error-codes-phase-3 branch from 79d0133 to 0077e04 Compare September 4, 2026 19:03

Roman-Manevich requested a review from hrutvik September 4, 2026 19:03

HadrienRenaud reviewed Sep 7, 2026

View reviewed changes

Base automatically changed from asl-error-codes-phase-2 to master September 7, 2026 09:12

Roman-Manevich force-pushed the asl-error-codes-phase-3 branch from 0077e04 to 3ca79fc Compare September 7, 2026 09:12

Roman-Manevich added 7 commits September 7, 2026 13:30

[asl] Correctly map lexical and parse errors to error codes

fe966d2

[asl][asl reference] Report global initialisation throws as DE_UE

7e2041b

[asl] Report dynamic type assertion failures as DE_TAF

27d1a34

[asl] Report static type assertion failures as TE_SEF

f5545cd

[asl] Map repeated tuple identifier writes to TE_IAD

4f249d7

[asl] Distinguish call and tuple arity errors

5662186

addressed review comments

3c1daa3

Roman-Manevich force-pushed the asl-error-codes-phase-3 branch from 3ca79fc to 3c1daa3 Compare September 7, 2026 21:27

Roman-Manevich requested a review from HadrienRenaud September 7, 2026 21:27

HadrienRenaud approved these changes Sep 8, 2026

View reviewed changes



		ASL Lexical error (BE_LE): Unknown symbol.
		ASL Lexical error (BE_LE): Unknown symbol "".

		\| BadCallArity of { name : identifier; expected : int; provided : int }
		\| BadTupleArity of { expected : int; actual : int }

Uh oh!

Conversation

Roman-Manevich commented Sep 4, 2026

Distinguish lexical and parse failures

Classify global-initialization exceptions

Classify asserted-type-conversion failures

Classify repeated tuple-field writes

Distinguish call and tuple arity failures

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hrutvik Sep 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Roman-Manevich Sep 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Roman-Manevich Sep 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HadrienRenaud left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

hrutvik Sep 7, 2026 •

edited

Loading

Roman-Manevich Sep 7, 2026 •

edited

Loading

Roman-Manevich Sep 7, 2026 •

edited

Loading