Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.5.23, 3.0.20, 4.0.17
-
None
Description
This is a follow-up of GROOVY-10561. The fix didn't handle the case when the default value included any kind of calculation. Example in the GroovyWebConsole
@NamedVariant baz(int v1 = 42, int v2 = v1+1, int v3 = v2+1) { "$v1 $v2 $v3" } assert baz() == '42 43 44' assert baz(10) == '10 11 12' assert baz(10, 20) == '10 20 21' assert baz(10, 20, 30) == '10 20 30' assert baz(v1: 10) == '10 11 12' assert baz(v1: 10, v2: 20) == '10 20 21' assert baz(v1: 10, v2: 20, v3: 30) == '10 20 30'
The generated code looks like this:
public java.lang.Object baz(@groovy.transform.NamedParams(value = [ @groovy.transform.NamedParam(value = 'v1', type = int, required = false), @groovy.transform.NamedParam(value = 'v2', type = int, required = false), @groovy.transform.NamedParam(value = 'v3', type = int, required = false) ]) java.util.Map namedArgs) { if (null == namedArgs ) { throw new java.lang.IllegalArgumentException('Named parameter map cannot be null') } for (java.lang.String namedArgKey : namedArgs.keySet()) { assert ['v1', 'v2', 'v3'].contains( namedArgKey ) : 'Unrecognized namedArgKey: ' + namedArgKey } return this.baz( namedArgs.containsKey('v1') ? namedArgs.v1 : 42, namedArgs.containsKey('v2') ? namedArgs.v2 : v1 + 1, namedArgs.containsKey('v3') ? namedArgs.v3 : v2 + 1) }
IMHO, it would be easiest to extract the map entries into local variables, then the references would be valid and would also work for cascading references.
Attachments
Issue Links
- is related to
-
GROOVY-10561 @NamedVariant self referential default values are not correctly resolved
- Closed
-
GROOVY-10889 Casting of arguments in @NamedVariant method has no effect
- Closed