Skip to content

Improve error messages #550

Description

@ducky64

Fixing common-cause error spam

Problem: lots of error messages caused by a missing value, either a undefined value or a generator failing to run.

Concept: introduce a concrete error type, #95. These follow propagation rules (untransformed) and errors are effectively 'shadowed' based on common cause. Eliminates need for a separate shadowing infrastructure / pass.

  • This handles explicit error cases properly. Generators errors populate all parameters (statically known) with concrete error values.
    • TBD: how to handle dynamic arrays? May need a port error type.
  • This does not handle missing values. But: blocks can be defined to require all values are set before compiling.
    • All self parameters and port parameters must be defined.
    • For generators, this is a post-generate check.
    • For blocks, arg-params are excluded. Instead, the instantiator must define arg-param values, that is checked as part of the instantiator's compile-time checks.
    • Missing values become a compiler internal construct.
  • Generalization: assertions can be resolved during compile time / expr evaluation, instead of as a separate pass. Checks walk the graph for error values. These are deduplicated in the compiler by object identity equality.

Error tracing

Problem: example: get an overvoltage / overcurrent error on a link, but no data as to which block (or port) the error is from.

Needs more thought about how to resolve this in a principled way. Typically the immediate cause is a failed constraint with nested exprs, eg require (union sources.voltage) within (intersect sinks.voltage_limits)

To resolve the specific cause (among a bunch of reduction operations), need some concept of tracing failing constraints.

Concept: at the top-level failing expr, it is assumed either side can be culprit, so there will be a lhs and rhs trace (or elt-wise trace for true arrays). eg for the lhs trace for lhs within rhs, it follows lhs backwards looking for which values violate the constraint. Effectively transforming the rhs concrete value each step up the lhs chain. Probably a lot of special-case evaluation rules, for each assertion (binary constraint) x operation (to back-walk).

This would return the entire trace as a tree, with the first branch being lhs vs. rhs, and further branches indicating different root causes where there are multiple. Back walking operates on fully concrete values, so an unknown / unmatched branch stops there and can be reported as a potential cause, until more cases are implemented.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions