Refactor Internals to use Scala 2 Veneers

[jackkoenig]

Happy to split this into multiple PRs, not sure if it's worth it or not.

This needs to be merged with a merge commit

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

• API modification

Desired Merge Strategy

• Rebase: You will rebase the PR onto master and it will be merged with a merge commit.

Release Notes

This is a massive refactoring of Chisel's internals in preparation for adding Scala 3 support. The public API should be generally unchanged but there are many new package private traits that should not affect Scala users but are messy at the binary compatibility level.

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), 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.

[adkian-sifive]

looks great so far. one thing i'd like to see is a scala-3 directory with some placeholder file that can successfully compile. though not necessarily as part of this pr

[jackkoenig]

looks great so far. one thing i'd like to see is a scala-3 directory with some placeholder file that can successfully compile. though not necessarily as part of this pr

Yeah that'll be good, but we should do that in a follow on PR as that will also require several other things (like the firrtl and svsim subprojects cross-compiling for Scala 3.

[jackkoenig]

A few points:

1. This introduces the concept of "Veeners" where the public API (e.g. class UInt) lives in src/main/scala-2 while the main implementation lives in a package private trait src/main/scala. It's a bit tedious but this is necessary for cross-compilation because we use macros in many our public APIs and macros are not source-compatible at all between Scala 2 and 3.¹
2. This is currently an omnibus PR but I am happy to split it up depending on what people think. If a single PR, it needs to be merged with a merge commit
3. I did not handle Definition.scala nor Instance.scala, those are a case where I think we can just stop using the macro because it's not clear to me that anyone needs chained apply when creating an Instance or Definition? Worth testing at least.
4. I also did not handle Printf.scala and VerificationStatement.scala, those ones are a lot trickier so I want to handle them on their own.
5. I worked very hard to preserve "git blame providence", currently a few files are not doing what I want so I will be rebasing shortly -- This is now done, see the several tactical "Rename" commits, those are why this PR needs a merge commit.
6. Most files were simple and mechanical, Bits.scala and Aggregate.scala were each a bit painful so may be worth a closer eye.

Footnotes

1. It just occurred to me that it may be possible to make the stuff in src/main/scala-2 be the private trait while the public class still lives in src/main/scala. Even still, that is not a huge change from how this is currently done, the bulk of the diff will be identical if we switch to that. We can also switch to that in subsequent PRs. ↩

[adkian-sifive]

LGTM

Perhaps in a future pr we can remove the implicit SourceInfo from the Impl files so that we can completely revamp source info in scala3.

[sequencer]

I personally suggest directly using https://github.com/com-lihaoyi/sourcecode rather than implementing our own for Scala 3 version of chisel.

[jackkoenig]

Perhaps in a future pr we can remove the implicit SourceInfo from the Impl files so that we can completely revamp source info in scala3.

I'm not sure I follow, what is wrong with the SourceInfo being implicit in the Impl files? We could make it explicit but I'm not sure that achieves anything.

I personally suggest directly using https://github.com/com-lihaoyi/sourcecode rather than implementing our own for Scala 3 version of chisel.

While, I understand the inclination to use libraries rather than implementing things ourselves (and @azidar has also expressed a desire to have source locators being a separate dependency from the single org.chipsalliance::chisel artifact`), this would be a massively backwards incompatible change that I think would unnecessarily complicate the transition--we want the delta between the Scala 2 and Scala 3 versions of Chisel to be as small as possible to make upgrading as easy as possible.

Considering it's about 5 lines of code to implement the SourceInfo macro, I don't think this is worth it. If we want to make such a transition, I think we should do it completely separately from the Scala 3 upgrade.

Also, probably making all of the above moot, sourcecode only supports local paths or absolute paths, neither of which fulfill our needs. We want project-local paths with some customization via System properties (or Scala compiler arguments if possible). So basically, I don't think we could use sourcecode even if it was worth the pain to migrate.

[jackkoenig]

@adkian-sifive I ended up going back and adding VecLikeImpl so no need to document the previous weirdness here.