Aligning implementation/specification error codes - phase 4

[Roman-Manevich]

Classify unsupported parameter expressions

Expressions that cannot define subprogram parameters now report TE_BSPD through BadParameterExpr, matching params_of_expr in asl.spec.

Classify invalid collection field types

Non-bitvector collection fields now report TE_UT through check_structure_bits, matching the per-field check_structure_label checks in asl.spec.

Classify unsupported parameter types

Types not permitted as subprogram argument or return types now report TE_BSPD through BadParameterType; asl.spec and a documented regression now cover pending-constrained integers, and the obsolete UnsupportedTy diagnostic is removed.

Classify out-of-bounds indices

Out-of-bounds native vector accesses now report DE_BI, or TE_SEF during static evaluation, through BadIndex instead of the uncoded MismatchType diagnostic.

Classify arbitrary negative-length arrays

Parameterized arrays whose length evaluates negatively now report DE_AET through ArbitraryEmptyType, matching EArbitrary in asl.spec.

Classify static evaluation failures

Static evaluation that does not produce a literal now reports TE_SEF through StaticEvaluationFailure, matching static_eval in asl.spec.

Classify implementation integer overflow

Integers exceeding OCaml int limits now report a structured internal ImplementationIntegerOverflow diagnostic instead of the uncoded UnsupportedExpr.

[HadrienRenaud]

worth a record I think

[Roman-Manevich]

I prefer records, but why this specific one and not all other constructors with multiple fields?

[hrutvik]

I can see at least two reasons:

• A record clearly differentiates between the two arguments with the same int type.
• This constructor was added in this PR - we can make it better quality than other constructors without being inconsistent.

[HadrienRenaud]

In general, I want to prevent this type of error: you have switched your arguments around and the type system does not catch it.
For example, it is not obvious that this code is wrong, and it will be accepted by the ocaml type-checker:

  fatal ~loc (Error.BadIndex (Static, actual, expected))

By naming things we can make this class of errors far more difficult to happen:

  fatal ~loc (Error.BadIndex { error_handling_time = Static; actual; expected })

This is the same reasoning for naming arguments to functions. The only exception to this is when it things are left-to-right ordered, e.g. plus x y makes as much sense as plus ~lhs:x ~rhs:y.

[HadrienRenaud]

Oh I had forgotten we had this limitation. Could we put it on a ticket please?

[Roman-Manevich]

I'm not sure what you want the ticket to say.

[HadrienRenaud]

Well that ASLRef does not support initialising constants with compound expressions when it is not forbidden by type-checking?

[hrutvik]

Please ensure @HadrienRenaud has approved before merging.

[hrutvik]

nit: why --gnu-errors here?