Community
Participate
Working Groups
If you make a reference to a restricted field of a parent class from a different component it does not get flagged as an error. For example: 1. you have two projects P1 and P2 2. you have a class C1 in P1 with a field F1 which has a noreference tag on it 3. you have a class C2 in P2 which extends P1 4. you have method in C2 that assigns a local variable the value of F1 -> public void noRef() { this.F2 = F1; } Expected: the ref to F1 would be flagged as an error Happens: nothing, likely we are not resolving field lookups like we do for virtual method sends. The given example does flag it properly if you qualify the access to F1 like -> super.F1
it also does not get flagged if F1 is qualified by 'this' or if F1 is accessed from an instance of the subclass -> main(..) { C2 c = new C2(); c.F1 = null; //does not get flagged }
I think the missing key here is that we need to do some additional processing with fields that are initialized when they are defined. It seems that field references in the <init> are not inspected properly. Currently we only check them to see if their type is an illegal ref not what we are assigning to them. Also when we find the super.F1 reference, it is reported as static access to the field F1...investigating.
I found two problems here: (1) We were not collecting GET FIELD/GET STATIC FIELD references... only puts (2) When a field reference is made we don't resolve it (so if its "this.field", we don't resolve what class actually defines the field).
Created attachment 99813 [details] patch This is a patch for (1) - creating the right kinds of references.
Filed bug 232139 to fix problem (1)
patch for part (1) has been applied. Still need to address (2) in a way that does not affect performance (too much).
Not planned for 3.4
Moving to 3.5 - not blocking anyone.
moving to 3.6
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.
