Community
Participate
Working Groups
Currently during code generation the source tree is passed in and there's no way to navigate to the target Java tree. I think we should change this to be the same as in ValidationParticipant.
Pushed to review https://git.eclipse.org/r/#/c/39295/
I'm not convinced by this change. Also it appears to be incomplete, unfortunately. This is how the CodeGenerationParticipant is currently described: /** * Invoked by the compiler during the code generation phase. * * @param annotatedSourceElements the immutable source representation (i.e. the Xtend AST) of the annotated elements * @param context a {@link TransformationContext} providing useful services. */ void doGenerateCode(List<? extends T> annotatedSourceElements, @Extension CodeGenerationContext context); Emphasize is on the parameter name 'annotatedSourceElements' and the described semantics. Changing that will introduce the problem that there may no longer be any target elements, since the AA processor may have removed all associations. Also it's not clear what the type parameter T should be in case the processor created different kinds of elements and doesn't have a primary generated Java element. This problem also applies to the validation participant. I'd rather add #getAllGeneratedJavaElements to the Tracibility service and pass the source elements to both the validation participant and the code generation participant. This would make the contract for the impl clearer.
You are right about the problematic corner cases, so passing in the annotated source elements would be correct. I'd like to skip the 'All' and go with getGeneratedJavaElements. Also Tracability#getPrimaryGeneratedJavaElement(Element) is typed to Element which makes it super inconvenient to work with. We should change it to be parameterized i.e. what goes in goes out, which means we cannot rely on the fuzzy contract to consider the first associated element being the primary. Instead we need to mark the element that was translated from the primary Xtend compiler explicitly. As a result it could be that getPrimaryJavaElement returns null while getJavaElements doesn't return an empty list.
(In reply to Sven Efftinge from comment #3) > Also > Tracability#getPrimaryGeneratedJavaElement(Element) is typed to Element > which makes it super inconvenient to work with. We should change it to be > parameterized i.e. what goes in goes out How would that parametrization look like? I think anything can be marked as 'primary' element, being it a class inferred from an formal parameter or a field inferred from a method. Should that be <E extends Element> E getPrimaryGeneratedJavaElement(Element in, Class<E> c). Or the unsafe version of <E extends Element> E getPrimaryGeneratedJavaElement(Element in)?
(In reply to Sebastian Zarnekow from comment #4) > (In reply to Sven Efftinge from comment #3) > > Also > > Tracability#getPrimaryGeneratedJavaElement(Element) is typed to Element > > which makes it super inconvenient to work with. We should change it to be > > parameterized i.e. what goes in goes out > > How would that parametrization look like? I think anything can be marked as > 'primary' element, being it a class inferred from an formal parameter or a > field inferred from a method. > > Should that be <E extends Element> E getPrimaryGeneratedJavaElement(Element > in, Class<E> c). Or the unsafe version of <E extends Element> E > getPrimaryGeneratedJavaElement(Element in)? I meant that only the XtendCompiler marks elements as primary. So I think it could be <E extends Element> E getPrimaryGeneratedJavaElement(E in)
(In reply to Sven Efftinge from comment #5) > I meant that only the XtendCompiler marks elements as primary. > So I think it could be > > <E extends Element> E getPrimaryGeneratedJavaElement(E in) I see, there wouldn't be an AA API that allows to mark an element as primary. I'm not sure how this aligns with other features like find references, where we use the "primary" element on the JVM side to find the references to a declaration.
(In reply to Sebastian Zarnekow from comment #6) > I see, there wouldn't be an AA API that allows to mark an element as > primary. I'm not sure how this aligns with other features like find > references, where we use the "primary" element on the JVM side to find the > references to a declaration. I think having an explicit API is the way to go as suggested in bug #457146.
