It relies on the observation that when a name is taken and we have
determined our disambiguation index, it's possible we don't actually
need to check the HashMap again to see if name + index is in it. We
would only need to do so if previously there has been a name added that
shares our prefix and happens to have an index itself. This commit is a
WIP to make this work, but it's quite hard to get right and the normal
names.get path needs to also do a prefix check. See the final test in
NamespaceSpec which fails (yay good tests!)

The namespace disambiguates requests for the same name with _<idx>.
Rather than storing every disambiguated name in the underlying HashMap,
it now only stores the base along with the "next available" index. This
makes the logic for checking if a name is already contained in the
namespace slightly more sophisticated because users can name things in a
way that will collide with disambiguated names from a common substring.

For example, in naming the sequence "foo", "foo", "foo_1", the 2nd "foo"
takes the name "foo_1" so the following "foo_1" gets disambiguated to
"foo_1_1". But since we compressed that original "foo_1" into the same
HashMap entry as just "foo", we have to do a form of "prefix checking"
whenever naming something that ends in "_<idx>".

In practice, the saved memory allocations more than make up for the more
complicated logic to disambiguate names because the common case is still
fast.

It used to be implemented with recursion, now it's implemented with a
stack safe reverse and foldLeft.

Also there were no tests for PriorityMux so I added one which helps
prove the change is functionally correct.

* Use SourceInfo in Builder error messages when available

* Use line break instead of semicolon

Co-authored-by: Jack Koenig <jack.koenig3@gmail.com>

Co-authored-by: Jack Koenig <jack.koenig3@gmail.com>

Move InjectingTransform to Chisel Phase

Adds a new call `getModulePortsAndLocators` which returns a list of 2-tuples of (Port, SourceLocators)
Fixed up internal calls to use the correct call

Co-authored-by: Jack Koenig <koenig@sifive.com>

* Change RawModule._commands to a VectorBuilder

Use the resulting Vector to build the underlying Component's commands
and then use those instead of copying the original ArrayBuffer when
iterating on commands. Previously, the Component was using a List to
hold the commands which is particularly memory inefficient, especially
for large modules.

* Optimize Converter's handling of Seq[Command]

It previously converted the Commands to a List (which, while not
captured in the type system, they were already a List) and then used
head and tail iteration. This is less efficient with the new underlying
Vector implementation.

This makes it more clear that the feature is experimental. Users may
still override the opaqueType method for more dynamic control over when
instances of a given Record are OpaqueTypes or not, but they are
discouraged from doing so.

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

* Bugfix: Output on Vec of bundle with mixed field orientations
* Bugfix OpaqueTypes clearing flips

Improve Record.bind and Detect Records with unstable elements

This replaces an immutable.Map with a single mutable.HashSet and saves
the allocation of # elements Seqs.

Vec overrides bind and does not call the version in Aggregate so the
version in Aggregate is misleading in that its only ever used by
Records. Now there is no version in Aggregate and the actual
functionality and use is more clear.

elementsIterator provides a more efficient API for iterating on the
elements of Aggregates. It is especially useful for Records where
getElements returns a Seq and thus eagerly constructs a new
datastructure which may then just be iterated on anyway.

This new elementsIterator API is then used throughout the codebase where
it makes sense.

Also change Vec.getElements to just return the underlying self instead
of constructing a new Seq.

Co-authored-by: Megan Wachs <megan@sifive.com>

This factory method makes it easy to create PartialDataViews from a
Bundle type to its supertype. Because of the typing relationship, there
is no need to provide a mapping between fields. The only thing necessary
is to provide a function for constructing an instance of the supertype
from an instance of the subtype.

* Add initial roadmap
Co-authored-by: edwardcwang <edwardcwang@users.noreply.github.com>

* add scalafmt for test in mill build system.
* reformat codes in integration-tests

MonoConnect.traceFlow now properly handles coerced directions.
Also minor improvement to getClassName especially useful in test case printf debugging.

* Don't invalidate ExtModule ports in an explicitInvalidate = true context

ExtModule ports were previously invalidated in the emitted FIRRTL, which is correct in a NonStrict / `Chisel._` compatibility context but not in newer chisel3 code where `explicitInvalidate = true`.

Don't modify the Builder prefix if reinvoking suggestName on a Data

Add utilities to enable backwards compatibility of the Trace.traceName
API to Chisel 3.5.x.  This adds a Trace.traceNameV2 utility which
aliases to Trace.traceName.  This also removes the TraceNameAnnotation
and renames it TraceAnnotation.  In 3.5.x, traceName will point at
TraceNameAnnotation (which has don't touch behavior) and will be
deprecated telling people to use traceNameV2 which will point at
TraceAnnotation (which does not have don't touch behavior).  This will
require fixups to the backport associated with this PR.

Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>

There is a new trait, chisel3.experimental.AutoCloneType that is mixed
in to Bundle and can optionally be mixed in to user-defined Records. The
compiler plugin prints a deprecation warning on any user-defined
implementation of cloneType, telling the user to mix in AutoCloneType
before upgrading to 3.6.

Chisel 3.5.4 predates Scala 2.13.10 so the plugin is not published for 2.13.10.

2.13.9 has a binary compatibility regression so should be avoided.

Change the behavior of the Trace API to not have "don't touch" behavior
unconditionally.  Removing "don't touch" enables a finer granularity of
functionality: if a user wants "don't touch" they can add a "don't
touch".  However, they are not locked optimization blocking behavior
which may be undesirable in certain situations.

Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>

Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>

Change the type of modules that the traceName API can be used for from
"Module" to "RawModule".  This fixes a bug where this API couldn't be
used for RawModules even though it totally works.

Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>

Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>