Add Groovy 4 support

[leonard84]

No description provided.

[szpak]

I started to work on the same a few days ago - still having some tests red (I could make a draft then, to do not duplicate our work :-/). However, I'm not sure, if we should release Spock 2.1-groovy-4.0 due to the reasons, I explained in #1374 (comment).

[leonard84]

I don't intend to release a 4.0 variant for 2.1 unless groovy 4.0 final is already release, but I don't want to wait that long.

[szpak]

I don't intend to release a 4.0 variant for 2.1 unless groovy 4.0 final is already release, but I don't want to wait that long.

Great, my plan was also to be ready with the stuff and eventually release SNAPSHOTs.

[szpak]

I merged in my initial changes with fixing stack trace related assertions broken by Indy calls (enabled by default in Groovy 4, but still possible with Groovy 2.5 and 3).

What's interesting, there all the tests are executed from Idea, two still fails with:

Condition not satisfied:

methodName == "-" || methodName == traceElem.methodName
|          |      |  |          |  |         |
|          |      |  |          |  |         foo_closure3
|          |      |  |          |  apackage.ASpec.foo_closure3(Script_3fd3a5801e374ef551955ab837465535.groovy:7)
|          |      |  |          false
|          |      |  |          1 difference (91% similarity)
|          |      |  |          foo_closure(1)
|          |      |  |          foo_closure(3)
|          |      |  foo_closure1
|          |      false
|          false
|          12 differences (0% similarity)
|          (foo_closure1)
|          (------------)
foo_closure1


	at org.spockframework.EmbeddedSpecification.stackTraceLooksLike_closure3(EmbeddedSpecification.groovy:58)
	at groovy.lang.Closure.call(Closure.java:419)
	at org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:318)
	at org.spockframework.EmbeddedSpecification.stackTraceLooksLike(EmbeddedSpecification.groovy:51)
	at org.spockframework.smoke.StackTraceFiltering.when creation of data provider fails, stack trace points to corresponding parameterization(StackTraceFiltering.groovy:229)

as for some reasons, there seems to be more closures in a generated script file (and own is no. 3). It doesn't happen when StackTraceFiltering tests are executed separately. I leave it for further investigation.

[codecov]

Codecov Report

Merging #1382 (50da321) into master (6e08587) will increase coverage by 0.10%.
The diff coverage is 52.17%.

@@             Coverage Diff              @@
##             master    #1382      +/-   ##
============================================
+ Coverage     79.36%   79.46%   +0.10%     
- Complexity     3987     3992       +5     
============================================
  Files           403      403              
  Lines         12413    12537     +124     
  Branches       1639     1642       +3     
============================================
+ Hits           9852     9963     +111     
- Misses         1968     1978      +10     
- Partials        593      596       +3     

Impacted Files	Coverage Δ
...a/org/spockframework/runtime/StackTraceFilter.java	97.56% <ø> (ø)
...framework/specs/jacoco/JacocoAstDumpTrigger.groovy	37.50% <25.00%> (-2.50%)	⬇️
...main/java/org/spockframework/compiler/AstUtil.java	80.28% <37.50%> (-1.95%)	⬇️
...java/org/spockframework/compiler/SpecRewriter.java	93.71% <70.00%> (-0.72%)	⬇️
...rg/spockframework/compiler/WhereBlockRewriter.java	94.01% <100.00%> (ø)
...c/main/groovy/spock/util/EmbeddedSpecRunner.groovy	84.21% <0.00%> (-0.87%)	⬇️
...rc/main/groovy/spock/util/matcher/IsCloseTo.groovy	100.00% <0.00%> (ø)
...ovy/spock/util/concurrent/BlockingVariables.groovy	80.00% <0.00%> (ø)
...ock/util/SourceToAstNodeAndSourceTranspiler.groovy	79.09% <0.00%> (+2.06%)	⬆️
... and 2 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6e08587...50da321. Read the comment docs.

[msgilligan]

I don't intend to release a 4.0 variant for 2.1 unless groovy 4.0 final is already release, but I don't want to wait that long.

The Groovy devs are voting on Groovy 4.0 final release as of today.

[szpak]

All CI build are green after I disabled @CompileStatic transformation in a few tests and test configuration classes.

However, I don't know why it fails that way and what's more strange, why some of those places fails also with JDK 8 and 11 (not just 17). Could we have some problem with build-cache on CI?
Another interesting thing is that I'm not able to reproduce (some) of those problems locally. Only the one place in the first "workaround" commit fails on my machine (with different JDKs). Those in Spring test configuration work fine (even with gw clean check -Dvariant=4.0 --no-build-cache).

I've just asked on the Groovy Slack about their ideas:
https://groovy-community.slack.com/archives/C2NEFCM55/p1643236824027100

Update. Paul pointed out the issue Leonard created in December :) - https://issues.apache.org/jira/browse/GROOVY-10403. Can we "fix" it on the Spock side?

In addition, I wonder, which Groovy 4 specific features (such as (emulated) sealed classes) you think are worth testing explicitly with Spock?

[szpak]

Btw, some tests are not stable on CI (just with this branch?).

One parallel test failed twice with JDK 8 and Groovy 3.0 and 4.0. However, it doesn't seem to be related:

ParallelSpec > @ResourceLock with only READ allows parallel execution of data-driven features FAILED
    Condition not satisfied:

    atomicInteger.get() == 3
    |             |     |
    3             1     false
        at apackage.ASpec.writeA(Script_9186d4f70d72d15ebba0478d4c746046.groovy:14)

Another one (in a separate run):

TimeoutExtension > stack trace shows where thread is hung FAILED
    org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple Failures (4 failures)
    	org.spockframework.runtime.SpockComparisonFailure: Condition not satisfied:

    trace.size() == lines.size()
    |     |      |  |     |
    |     1      |  |     2
    |            |  [apackage.ASpec|helper|7,       apackage.ASpec|foo|3]
    |            false
    [apackage.ASpec.foo(Script_4c375ed6a7d6b75b709b5b6f940f6e5c.groovy:3)]

    	org.spockframework.runtime.SpockComparisonFailure: Condition not satisfied:

    trace.size() == lines.size()
    |     |      |  |     |
    |     1      |  |     2
    |            |  [apackage.ASpec|helper|7,       apackage.ASpec|foo|3]
    |            false
    [apackage.ASpec.foo(Script_4c375ed6a7d6b75b709b5b6f940f6e5c.groovy:3)]

    	org.spockframework.runtime.WrongExceptionThrownError: Expected exception of type 'org.spockframework.runtime.SpockTimeoutError', but no exception was thrown
    	org.spockframework.runtime.WrongExceptionThrownError: Expected exception of type 'org.spockframework.runtime.SpockTimeoutError', but no exception was thrown
        at org.spockframework.runtime.ErrorInfoCollector.assertEmpty(ErrorInfoCollector.java:32)
        at org.spockframework.runtime.IterationNode.execute(IterationNode.java:49)

[lptr]

Given that Spock 2.1 is not released yet, and that Groovy 4 is released now, is this going to make it into Spock 2.1?

[szpak]

Given that Spock 2.1 is not released yet, and that Groovy 4 is released now, is this going to make it into Spock 2.1?

Groovy 4 GA is out, so assuming no other obstacles, it will be a part of 2.1.

[eric-milles]

Can the reference to Groovy 4 RC2 be updated? For the "explain why compilation started to fail", do you need some help looking at something?

[szpak]

Can the reference to Groovy 4 RC2 be updated?

I've just updated it. Thanks for your reminder.