• Top
    • Documentation
    • Books
    • Boolean-reasoning
    • Projects
    • Debugging
    • Std
    • Community
    • Proof-automation
    • Macro-libraries
    • ACL2
    • Interfacing-tools
    • Hardware-verification
      • Gl
      • Esim
      • Vl2014
      • Sv
      • Fgl
      • Vwsim
      • Vl
        • Syntax
        • Loader
        • Warnings
          • Lint-warning-suppression
          • Warning-basics
          • Vl-warning
          • Vl-warninglist-add-ctx
          • Vl-warninglist->types
          • Propagating-errors
            • Vl-design-propagate-errors
            • Vl-blamealist
              • Vl-blamealist-p
              • Vl-blamealist-fix
              • Vl-blamealist-equiv
            • Vl-design-zombies
            • Vl-blame-alist-to-reportcard
            • Vl-blame-alist
            • Vl-blamealist-count
          • Vl-reportcard
          • Vl-some-warning-fatalp
          • Clean-warnings
          • Lint-whole-file-suppression
          • Warn
          • Vl-warninglist
          • Vl-remove-warnings
          • Vl-keep-warnings
          • Flat-warnings
          • Vl-some-warning-of-type-p
          • Vl-msg
          • Vl-warning-add-ctx
          • Vl-print-warning
          • Vmsg-binary-concat
          • Ok
          • Vl-trace-warnings
          • Fatal
          • Vmsg
        • Getting-started
        • Utilities
        • Printer
        • Kit
        • Mlib
        • Transforms
      • X86isa
      • Svl
      • Rtl
    • Software-verification
    • Math
    • Testing-utilities
  • Propagating-errors

Vl-blamealist

A record of which submodules are to blame for transitive failures to translate modules.

Explanation of Blame Alists

Suppose we are transforming a list of modules, and we run into problems in some module, M. More generally we might run into a problem with a design element other than a module, such as an interface, but we'll pretend for the moment that there are only modules.

Our basic goal for propagating-errors is to:

  • Add a warning onto M that says why we had the problem, and
  • Remove M from the list of modules, so that we can continue with the other modules.

But this isn't really good enough.

Besides removing M, we should also remove any dependents (see hierarchy) of M, since removing M would cause these modules to be incomplete.

As we remove these dependent modules, we would also like to annotate them with warnings explaining that they are being removed because of problems with M.

In general, instead of a single "bad" module, imagine that we have a list of bad modules, B1, ..., Bn. Moreover,

  • Let deps(Bi) be the set of all modules that (transitively) depend on Bi.
  • Let D be the union over deps(Bi), i.e., D is the set of all modules that depend on any bad module)

Note that there is no generally reason to think that deps(Bi) is disjoint from deps(Bj). If a module M instantiates both Bi and Bj, then it will be in the dependents for both of them. So, which one should be blamed?

Our approach is to blame them both. To do this, we first construct a blame alist.

A blame alist includes an entry for every module M in D. That is, it has an entry for every module that is going to be transitively killed. In particular, we want to associate, with each such M with the set of the "root problem modules" that it depends on, i.e., with:

{ Bi : M in deps(Bi) }

Once the blame alist is constructed, we can easily use it to annotate each module in its domain with a warning that says which modules are to blame for its removal.

Subtopics

Vl-blamealist-p
Recognizer for vl-blamealist.
Vl-blamealist-fix
(vl-blamealist-fix x) is an fty alist fixing function that follows the fix-keys strategy.
Vl-blamealist-equiv
Basic equivalence relation for vl-blamealist structures.