[ 
https://issues.apache.org/jira/browse/GROOVY-12023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18085634#comment-18085634
 ] 

ASF GitHub Bot commented on GROOVY-12023:
-----------------------------------------

testlens-app[bot] commented on PR #2549:
URL: https://github.com/apache/groovy/pull/2549#issuecomment-4607781686

   ## 🚨 TestLens detected 1 failed test 🚨
   
   Here is what you can do:
   
   1) Inspect the test failures carefully.
   2) If you are convinced that some of the tests are flaky, you can mute them 
below.
   3) Finally, trigger a rerun by checking the rerun checkbox.
   
   ### Test Summary
   
   | Check | Project/Task | Test | Runs |
   |---|---|---|---|
   | [Build and test / lts \(25, 
ubuntu-latest\)](https://github.com/apache/groovy/actions/runs/26853180570/job/79189929614?pr=2549)
 | :test | GenericsSTCTest > testReturnTypeInferenceWithMethodGenerics18\(\) | 
❌ |
   
   🏷️ Commit: 668423c6caee9388d1167231aa3a7059c2ab9b16
   ▶️ Tests:  120253 executed
   🟡 Checks: 18/56 completed
   
   ### Test Failures
   
   <details>
   
   <summary><strong>GenericsSTCTest > 
testReturnTypeInferenceWithMethodGenerics18()</strong> (:test in <a 
href="https://github.com/apache/groovy/actions/runs/26853180570/job/79189929614?pr=2549";>Build
 and test / lts (25, ubuntu-latest)</a>)</summary>
   
   ```
   org.codehaus.groovy.control.MultipleCompilationErrorsException: startup 
failed:
   TestScript0a3607d8577841bb84fd4a991bc70d7a.groovy: 5: unable to resolve 
class ListMultimap<java.lang.String, java.lang.Integer>
    @ line 5, column 43.
                  ListMultimap<String, Integer> mmap = 
ArrayListMultimap.create()
                                                ^
   
   1 error
   
        at 
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:333)
        at 
org.codehaus.groovy.control.CompilationUnit$ISourceUnitOperation.doPhaseOperation(CompilationUnit.java:989)
        at 
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:749)
        at 
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:723)
        at 
groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:423)
        at 
groovy.lang.GroovyClassLoader.lambda$parseClass$3(GroovyClassLoader.java:364)
        at 
org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache.getAndPut(ConcurrentCommonCache.java:143)
        at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:364)
        at groovy.lang.GroovyShell.parseClass(GroovyShell.java:665)
        at groovy.lang.GroovyShell.parse(GroovyShell.java:678)
        at groovy.lang.GroovyShell.parse(GroovyShell.java:690)
        at groovy.lang.GroovyShell.evaluate(GroovyShell.java:552)
        at groovy.lang.GroovyShell.evaluate(GroovyShell.java:588)
        at groovy.lang.GroovyShell.evaluate(GroovyShell.java:572)
        at 
groovy.transform.stc.StaticTypeCheckingTestCase.assertScript(StaticTypeCheckingTestCase.groovy:78)
        at 
groovy.transform.stc.GenericsSTCTest.testReturnTypeInferenceWithMethodGenerics18(GenericsSTCTest.groovy:701)
   ```
   
   </details>
   
   ### Muted Tests
   > [!NOTE]
   > Checks are currently running using the configuration below.
   
   Select tests to mute in this pull request:
   
   🔲 GenericsSTCTest > testReturnTypeInferenceWithMethodGenerics18\(\) <!

> create a PIC for indy
> ---------------------
>
>                 Key: GROOVY-12023
>                 URL: https://issues.apache.org/jira/browse/GROOVY-12023
>             Project: Groovy
>          Issue Type: Bug
>            Reporter: Jochen Theodorou
>            Assignee: Jochen Theodorou
>            Priority: Major
>
> What we currently have is essentially a two layer system in which we have the 
> target handle and cache for everything else. This can be seen as a PIC of 
> size 1 with a fallback cache for megamorphic cases. Here I propose to 
> implement a PIC of at least size 3 consisting of method handles where the 
> guard will use the next PIC element as fallback instead of going to the 
> cache. The goal is to reach a more stable configuration on the callsite for 
> JIT to optimize. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to