Motivation

Ever since #164, we have some control over phase, scoverage-instrument. We can just specify which phase the scoverage-instrument should sit in by supplying a compiler option -P:scoverage:extraBeforePhase:<phaseName> and -P:scoverage:extraAfterPhase:<phaseName>.

However, while normally up to one customized phase is enough, my use case is somewhat peculiar. I was working on a personal project which relies on chipsalliance/chisel and to generate coverage without any issue, scoverage-instrument must run before two phases, not just one.

That's because chisel's plugin generates additional AST on the fly. Here's an example:

else if (isData || isPrefixed) {
  val prefixed = q"chisel3.experimental.prefix.apply[$tpt](name=$prefix)(f=$newRHS)"

  val named =
    if (isNamedComp) {
      // Only name named components (not things that are merely prefixed)
      q"chisel3.internal.plugin.autoNameRecursively($str)($prefixed)"
    } else {
      prefixed
    }

  treeCopy.ValDef(dd, mods, name, tpt, localTyper.typed(named))
}

Source: https://github.com/chipsalliance/chisel/blob/v3.6.1/plugin/src/main/scala/chisel3/internal/plugin/ChiselComponent.scala#L194

Without specifying any of extraBeforePhase and extraAfterPhase, scoverage plugin emits following warnings (on 1.9.0, now it's error afterwards).

[info] [warn] Could not instrument [Literal/null]. No pos.
[info] [warn] Could not instrument [Literal/null]. No pos.
[info] [warn] Could not instrument [Literal/null]. No pos.
[info] [warn] Could not instrument [Apply/method autoNameRecursively]. No pos.
[info] [warn] Could not instrument [Literal/null]. No pos.
[info] [warn] Could not instrument [Apply/method autoNameRecursively]. No pos.
[info] [warn] Could not instrument [Apply/method apply]. No pos.
[info] [warn] Could not instrument [Apply/method autoNameRecursively]. No pos.

As described above, the only way to solve this is putting scoverage-instrument ahead of chisel's phases, called chiselbundlephase and chiselcomponent.

I can't simply disable such plugins because they're simply indispensible to generate a hardware code. Before this pull request, I've devised a dummy plugin to workaround such ordering issue. However, that approach is only a temporary measure, so I decided to file this feature request as well.

Change Summary

• Let user specify multiple phases via -P option.
  • Ex. -P:scoverage:extraBeforePhase:chiselcomponent;chiselbundlephase
  • Used ; as a delimiter to match the style of other options like excludedSymbols and so on.

Related issues / PRs

• Configurable extra runsBefore and runsAfter phases #164