Implement auto typeName generation for Records

[jared-barocsi]

Adds the HasAutoTypename trait, which mixes into Record and generates a def typeName statement constructed from the Record's constructor parameters.

Example:

class MyBundle(foo: Int, bar: Int) extends Bundle with HasAutoTypename {
  val x = UInt(foo.W)
  val x = UInt(foo.W)
  // This line is automatically generated by the compiler plugin through HasAutoTypename
  // override def typeName: String = s"${getClass.getSimpleName}_$foo_$bar"
}

val bundle = Wire(new MyBundle(8, 4))
bundle.typeName // MyBundle_8_4

Contributor Checklist

• Did you add Scaladoc to every public function/method?
• Did you add at least one test demonstrating the PR?
• Did you delete any extraneous printlns/debugging code?
• Did you specify the type of improvement?
• Did you add appropriate documentation in docs/src?
• Did you request a desired merge strategy?
• Did you add text to be included in the Release Notes for this change?

Type of Improvement

• New API

Desired Merge Strategy

Squash and merge

Release Notes

Add experimental HasAutoTypename trait

• Allows users to automatically generate a typeName for Bundle objects through the compiler plugin.

Reviewer Checklist (only modified by reviewer)

• Did you add the appropriate labels? (Select the most appropriate one based on the "Type of Improvement")
• Did you mark the proper milestone (Bug fix: 3.5.x, 3.6.x, or 5.x depending on impact, API modification or big change: 6.0)?
• Did you review?
• Did you check whether all relevant Contributor checkboxes have been checked?
• Did you do one of the following when ready to merge:
  • Squash: You/ the contributor Enable auto-merge (squash), clean up the commit message, and label with Please Merge.
  • Merge: Ensure that contributor has cleaned up their commit history, then merge with Create a merge commit.

[jackkoenig]

Generally looks good but please remove the code duplication in the plugin. Per anonymous Bundle issues, we can deal with that in a follow on PR.

[jackkoenig]

We should probably think about what the behavior should be for anonymous classes, eg. what if someone writes:

class MyModule(n: Int) extends Module {
  val io = IO(new Bundle with HasAutoTypename {
    val foo = Input(UInt(n.W))
  })
}

I think you will get a name that is something like _packageMyModulee0e14f5_8 which is a pretty terrible name indeed.

I think there's a compelling argument that you should not be able to mix HasAutoTypename into anonymous classes since it's going to be a disaster, and arguably not any inner class (inner classes have their outer object as the first argument, that's where packageMyModuleee0e145f comes from, that's the .toString of the instance of MyModule above).

Also .getSimpleName throws an exception in some circumstances on Java8 which is still supported by Chisel, see scala/bug#2034 and this is why we have more complicated logic for naming Modules:

chisel/core/src/main/scala/chisel3/Module.scala

Line 507 in 8b60f19

def desiredName: String = {

I'm not going to sandbag this PR of this issue, but more careful handling either needs to be in this PR or come shortly after.

[jackkoenig]

We chatted offline but I think the best path forward is to just find a way to ban inner classes from using HasAutoTypename in the compiler plugin, then we don't need to worry about the .getSimpleName issue either because that only affects inner classes.

[jackkoenig]

Please add a test for a Bundle with multiple parameter lists, including implicit eg.

class MultipleParameterLists(x: Int)(y: List[Int])(implicit z: String) extends Bundle with HasAutoTypename { ... }

[jackkoenig]

Approved but please add the requested test and address Megan's comments about the ScalaDoc