RegEnable does not take named arguments

[iansseijelly]

Type of issue: Bug Report

Please provide the steps to reproduce the problem:
Any Chisel design using RegEnable(next=x_next, enable=x_en) instead of RegEnable(x_next, x_en)

What is the current behavior?

[Error]:macro applications do not support named and/or default arguments

What is the expected behavior?
It should work and it was working in previous versions.

What is the use case for changing the behavior?
Adding named arguments makes the register declaration much more readable, especially for use cases where declaring separate enable and next wires does not make sense.

[jackkoenig]

I agree that it would be nice to take named arguments, but it's a fundamental limitation of def macros in Scala 2. This fundamental limitation is fixed in Scala 3 so this is a "Wont Fix" in the Scala 2 version of Chisel, but this will be fixed by virtue of upgrading to Scala 3 when we finally do that (hopefully in the coming months).

[jerryz123]

@jackkoenig is there any info on the Scala 3 upgrade? Is this the 7.0.0 release? Is there any migration plan?

[jackkoenig]

Probably not in 7.0.0, or at least I certainly won't hold up a 7.0 for it. No formal migration plan except that at least initially Chisel will cross-compile for 2.13 and 3 so that users can bump Chisel, and then migrate to Scala 3. There are some relatively minor but nevertheless backwards incompatible changes we need to make before upgrading to Scala 3.

1. We have to remove this.type, we can make cloneType work as an extension method. This change should be source compatible but is very much not binary compatible (mandating the change be on a major version bump).
2. Scala 3 doesn't support macro annotations in the same way, so D/I needs to switch to a different implementation. I have prototyped how to do it using whitebox def macros, @instantiable and @public will go away. I think we need to make this change in a major version bump before we try to add Scala 3 support, otherwise I don't see how lots of code will cross-compile which would be a huge pain.

Depending on maintenance burden I would like to support cross-compilation for a while.