[Scala3] Update BundleSelect to support refined structural type access

[adkian-sifive]

This issue cropped up in tests. BundleSelect did not support refining types which led to errors on anonymous Bundles. After these changes the structural refinement more closely mimics Scala 2 behavior

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

• Feature (or new API)
• API modification
• API deprecation
• Backend code generation
• Performance improvement
• Bugfix
• Documentation or website-related
• Dependency update
• Internal or build-related (includes code refactoring/cleanup)

Desired Merge Strategy

• Squash: The PR will be squashed and merged (choose this if you have no preference).
• Rebase: You will rebase the PR onto master and it will be merged with a merge commit.

Release Notes

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.6.x, 5.x, or 6.x depending on impact, API modification or big change: 7.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) and clean up the commit message.
  • Merge: Ensure that contributor has cleaned up their commit history, then merge with Create a merge commit.

[jackkoenig]

I don't think this is the right way to fix whatever it's fixing, and trying to understand why this fixes anything made me realize something:

I think our whole approach to Selectable is slightly wrong. We're implementing it for the Data fields that we support (and this PR fixes it for fields whos names don't match their sanitized names), but Selectable should also work for non-Data fields, consider:

val io = IO(new Bundle {
  val out = Output(UInt(8.W))
  val foo = 3
})

Our current implementation works for io.out, but it should also work for io.foo (and does in Scala 2).

Scala 3 provides an implementation of the reflective implementation in scala.reflect.Selectable. Now we could fix this by just mixing that in stead of scala.Selectable but I don't think we should that either.

If we ever want to move away from supporting Selectable (and urging users away from using anonymous types), it would be a hard breaking change to move to scala.Selectable from scala.reflect.Selectable. It is better to stick with scala.Selectable but still use the reflective implementation which we can do a number of different ways, but I think the easiest way is:

extension (b: Bundle) {
  def selectDynamic(field: String): Any = {
    val impl = new scala.reflect.Selectable {
      override protected def selectedValue = b
    }
    impl.selectDynamic(field)                                                                                                                    
  }
}

This basically lets us continue mixin scala.Selectable but get the benefits of the reflective implementation.

Relatedly, I'm not sure why we have Record mixing in Selectable but then have this extension on Bundle, do you know why?

[adkian-sifive]

I feel like we shouldn't support non-Data fields being selectable -- I see non-data fields, like val foo in your example Bundle, as parameters rather than part of a Bundle's structural type

[adkian-sifive]

Although I guess if Scala 2 supports it we shouldn't be breaking it just yet, lemme try the scala.reflect.Selectable change