Community
Participate
Working Groups
Created attachment 239644 [details] Testcase provided by Stephan. Attached is the test case for the quick fixes UI has to support, make sure all test passes when this issue is fixed.
I'd like to resolve this before GA, but the interface between Core and UI deserves discussion. Consider these examples: public class QF { void m(@NonNull Map<@NonNull String, @Nullable Object> map) { } void test1(@NonNull HashMap<String, @Nullable Object> map1) { m(map1); } void test2(HashMap<@NonNull String, @Nullable Object> map2) { m(map2); } } Currently both calls to m() trigger the same IProblem.NullityUncheckedTypeAnnotationDetail spelled out like this (first call): "Null type safety (type annotations): The expression of type '@NonNull HashMap<String,@Nullable Object>' needs unchecked conversion to conform to '@NonNull Map<@NonNull String,@Nullable Object>'" The question is: how does the QuickFix know where to add/remove the annotation(s)? In test1 the mismatch concerns a type argument, in test2 it's the main type. I think the coolest solution would be: - compiler attaches an annotated TypeBinding representing the "suggested" type" - quickfix compares the suggested type to the actual type and updates annotations to make both match. I wouldn't burden UI with computing the "suggested type", because that can be tricky to determine, as illustrated here: class StringKeyedMap<T> extends HashMap<@NonNull String,T> { } class QF2 { void m(@NonNull Map<@NonNull String, @Nullable Object> map) { } void test3() { @NonNull StringKeyedMap<Object> map3 = new StringKeyedMap<>(); m(map3); } } Here we have a mismatch between: - provided: @NonNull StringKeyedMap<Object> - required: @NonNull Map<@NonNull String,@Nullable Object> How do we make the connection between type parameters of different types? The compiler has the machinery for this kind of analysis, so it can provide actually two "suggested types": - either correct the provided to '@NonNull StringKeyedMap<@Nullable Object>' - or correct the required to '@NonNull Map<@NonNull String,Object>' Now for the interface: I could tweak two compiler TypeBindings into the DefaultProblem. Question: Is JDT/UI comfortable with extracting information from these two compiler internal classes? I probably cannot offer anything public, because the compiler cannot use dom bindings or such. Any ideas? Some public bridge in the dom package that holds a BindingResolver, and when given a DefaultProblem/IProblem it will answer the contained bindings translated into dom bindings? --- If this approach doesn't fly, we'd have to design some new "path" abstraction, (like in type annotation class file representation) pointing to the location(s) needing an annotation update.
See also bug 440306.
Bug 458186 comment 4 contains a small step in this direction.
Ran out of time for 4.7. Bulk move to 4.8.
Not sure there's any low hanging fruit remaining in this area.
.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
