Workaround for Eclipse JDT/APT bug around intersection types #305
Conversation
When in presence of a TypeVariable with an intersection type as the upper bound, Eclipse JDT/APT returns a TypeVariable equivalent to the declaring TypeVariable when calling getUpperBound. The only way to retrieve the actual bounds is to go look at the TypeParameterElement represented by the TypeVariable.
|
I'm absolutely not fond (read: I find it ugly) of the copied |
| } | ||
|
|
||
| static private boolean compile(Iterable<? extends Processor> processors) { | ||
| JavaCompiler compiler = new EclipseCompiler(); |
There was a problem hiding this comment.
Would I be right in thinking that the need for this copied @Rule would go away if the original CompilationRule had an optional constructor parameter that was a JavaCompiler or a Supplier<JavaCompiler>? That seems as if it would be a very useful thing for cases like this. What does @gk5885 think?
There was a problem hiding this comment.
That's right, that's the only required change.
There was a problem hiding this comment.
Occasionally I try to take a stab at making compile testing work with ecj, but end up running into walls where it makes assumptions about the implementation of the filer and whatnot and ends up crashing. I haven't tried in particular with CompilationRule though. It might work, but I wouldn't be remotely surprised if it didn't either.
There was a problem hiding this comment.
Ah right, I also had to change from compiling dummy sources to processing a class instead, because ECJ requires "all JavaFileObjects be Files" as you note in google/compile-testing#31.
So maybe CompilationRule could just use the JavaCompiler directly taking into account those limitations, rather than calling Compilation.compile(). AFAICT, it doesn't really need an InMemoryJavaFileManager either, or processing the diagnostics, so it would be really simple (well, just like the rule in this PR)
|
I'll revisit this PR once google/compile-testing#71 is merged. I might revisit it earlier though wrt the simplification discussed in #303 to unconditionally use |
|
Wow, that's involved! Should I merge as-is and you can follow up? |
There's actually no need to deal with intersection types as type mirrors, we can just go down to the TypeParameterElement and directly get its bounds.
|
I just added a commit with the simplification; I also added a It's good to merge IMO, and we can follow up with a simplification to the tests when compile-testing makes it possible. |
Workaround for Eclipse JDT/APT bug around intersection types
|
Works for me. Merged. Thanks @tbroyer ! |
When in presence of a TypeVariable with an intersection type as the upper
bound, Eclipse JDT/APT returns a TypeVariable equivalent to the declaring
TypeVariable when calling getUpperBound. The only way to retrieve the
actual bounds is to go look at the TypeParameterElement represented by
the TypeVariable.
See #303