groovy
  1. groovy
  2. GROOVY-4711

Standalone stub generation task fails resolving classes

    Details

    • Patch Submitted:
      Yes
    • Number of attachments :
      1

      Description

      If you create a Java class (Foo) and a Groovy class (Bar extends Foo), and then run the stub generation Ant task (GenerateStubsTask), it'll fail because it now does all the phases up to semantic analysis which attempts to resolve all class references. AFAIU the stub generation is supposed to be run before Javac. So it should be prepared that some Java classes the Groovy code depends on aren't compiled yet.

        Activity

        Hide
        blackdrag blackdrag added a comment -

        but joint compilation using groovyc works, or not?

        Show
        blackdrag blackdrag added a comment - but joint compilation using groovyc works, or not?
        Hide
        Roshan Dawrani added a comment -

        Since no other information is provided, if I just try:

        Foo.java

        class Foo {}
        

        and Bar.groovy:

        class Bar extends Foo {}
        

        and compile as

        groovyc *
        

        then the joint compilation goes through just fine (using groovy 1.7.5).

        Show
        Roshan Dawrani added a comment - Since no other information is provided, if I just try: Foo.java class Foo {} and Bar.groovy: class Bar extends Foo {} and compile as groovyc * then the joint compilation goes through just fine (using groovy 1.7.5).
        Hide
        Roshan Dawrani added a comment -

        With groovyc 1.7.8, it works too.

        Show
        Roshan Dawrani added a comment - With groovyc 1.7.8, it works too.
        Hide
        Peter Gromov added a comment -

        The problem is that we need stub generation as a separate step, our (IntelliJ IDEA) build is a quite complex process, it consists of many stages and stub generation and javac/groovyc happen to be on different stages.

        The joint compilation works indeed, because the stub generation there happens twice: once during conversion and the other time during semantic analysis. The stub generated in conversion gets immediately compiled by Javac (see JavaAwareCompilationUnit), and so it is available for resolve during the semantic analysis. In a separate standalone stub generator (GenerateStubsTask, JavaStubCompilationUnit) semantic analysis also happens, but nobody has generated and compiled the stubs together with the Java sources before that, so the resolve fails.

        Show
        Peter Gromov added a comment - The problem is that we need stub generation as a separate step, our (IntelliJ IDEA) build is a quite complex process, it consists of many stages and stub generation and javac/groovyc happen to be on different stages. The joint compilation works indeed, because the stub generation there happens twice: once during conversion and the other time during semantic analysis. The stub generated in conversion gets immediately compiled by Javac (see JavaAwareCompilationUnit), and so it is available for resolve during the semantic analysis. In a separate standalone stub generator (GenerateStubsTask, JavaStubCompilationUnit) semantic analysis also happens, but nobody has generated and compiled the stubs together with the Java sources before that, so the resolve fails.
        Hide
        Guillaume Laforge added a comment -

        Peter, perhaps you could explain a bit more concretely what you would like to see? What would help IntelliJ IDEA? That everything runs in CONVERSION phase, or something like that?

        Show
        Guillaume Laforge added a comment - Peter, perhaps you could explain a bit more concretely what you would like to see? What would help IntelliJ IDEA? That everything runs in CONVERSION phase, or something like that?
        Hide
        Peter Gromov added a comment -

        It would help if the resolve process didn't fail the compilation. This can be achieved by making the standalone stub generation not run it (i.e. to work only up to the conversion phase) or just ignore the unresolved references during the semantic analysis. The first alternative means even wider gap between joint compilation and just stub generation, the second one looks a bit like a hack. But both would work for us.

        Show
        Peter Gromov added a comment - It would help if the resolve process didn't fail the compilation. This can be achieved by making the standalone stub generation not run it (i.e. to work only up to the conversion phase) or just ignore the unresolved references during the semantic analysis. The first alternative means even wider gap between joint compilation and just stub generation, the second one looks a bit like a hack. But both would work for us.
        Hide
        blackdrag blackdrag added a comment -

        I attached a patch. It aligns the stub task with our joint compilation more in such that it moves the stub generation to the conversion phase and also does the VariableScopeVisitor and JavaAwareResolveVisitor runs before. Since this is a bigger change to the stub generator task we will include that only after 1.8.0

        But before this can be really included we absolutely need some tests I think

        Show
        blackdrag blackdrag added a comment - I attached a patch. It aligns the stub task with our joint compilation more in such that it moves the stub generation to the conversion phase and also does the VariableScopeVisitor and JavaAwareResolveVisitor runs before. Since this is a bigger change to the stub generator task we will include that only after 1.8.0 But before this can be really included we absolutely need some tests I think
        Hide
        blackdrag blackdrag added a comment -

        Peter if you would test that patch it would surely help us

        Show
        blackdrag blackdrag added a comment - Peter if you would test that patch it would surely help us
        Hide
        Peter Gromov added a comment -

        Jochen,

        Unfortunately I don't have much time now to build Groovy and try it, but from the first shallow glance the patch looks good. And I'd include this into 1.7.x for the following reason: JavaStubCompilationUnit is used only from the commented out generatestubs task, and currently this will definitely fail (when doing clean build) when there's at least one Groovy file referencing at least one Java class. As no one but me came with this problem, I assume we're the only clients of this task. So nothing should break except possibly for us, which in turn shouldn't happen. And I agree that having a test would be great.

        Show
        Peter Gromov added a comment - Jochen, Unfortunately I don't have much time now to build Groovy and try it, but from the first shallow glance the patch looks good. And I'd include this into 1.7.x for the following reason: JavaStubCompilationUnit is used only from the commented out generatestubs task, and currently this will definitely fail (when doing clean build) when there's at least one Groovy file referencing at least one Java class. As no one but me came with this problem, I assume we're the only clients of this task. So nothing should break except possibly for us, which in turn shouldn't happen. And I agree that having a test would be great.
        Hide
        Peter Gromov added a comment -

        Jochen, I've built Groovy with this patch and it works. You've promised me you'll apply it

        Show
        Peter Gromov added a comment - Jochen, I've built Groovy with this patch and it works. You've promised me you'll apply it
        Hide
        blackdrag blackdrag added a comment -

        Peter, sorry for not appllying the patch earlier, now it is done.

        Show
        blackdrag blackdrag added a comment - Peter, sorry for not appllying the patch earlier, now it is done.

          People

          • Assignee:
            blackdrag blackdrag
            Reporter:
            Peter Gromov
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: