This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Rich managed to find a case involving multiple source roots compiling to a single output directory with shadowing which tickles the incorrect error badge bug. He says this is representative of actual problems on his own sources. To reproduce: 1. Unpack the attachment to disk. 2. Open contrib/autoproject.kit as main and press Debug. 3. In the started IDE, open the unpacked project. 4. Press Build and select the 'build' target. The Ant build should complete normally. 5. Expand patchery/src2b/<default package>. (The order in which you expand nodes does seem to matter!) After a moment, an error badge will appear on src2. 6. Open src2/<default package>/A.java - it will appear green and after a moment the error badges will disappear again. (If you expand src3b first, then src3/B.java will be marked erroneous at first.) Diagnostic notes: nbbuild/testuserdir/var/cache/autoprojects.properties should show reasonable information matching the build script: ... /tmp/patchery/src2#binary=/tmp/patchery/build/clz2 /tmp/patchery/src2#classpath=\ /tmp/patchery/build/clz2:\ /tmp/patchery/build/clz1 /tmp/patchery/src2#source=/tmp/patchery/src2 /tmp/patchery/src2b#binary=/tmp/patchery/build/clz2 /tmp/patchery/src2b#classpath=\ /tmp/patchery/build/clz2:\ /tmp/patchery/build/clz1 /tmp/patchery/src2b#source=/tmp/patchery/src2b ... And as far as I know the various queries in the module are responding correctly as well, as can be seen in console output: FINE [org.netbeans.modules.autoproject.java.SourceForBinaryImpl]: sources of /tmp/patchery/build/clz2: [/tmp/patchery/src2, /tmp/patchery/src2b] The error badge autocorrection is active and functional, so this is just a matter of the initial status being wrong: WARNING [org.netbeans.modules.java.source.tasklist.IncorrectErrorBadges]: Incorrect error badges detected, file=/tmp/patchery/src2/A.java. WARNING [org.netbeans.modules.java.source.tasklist.IncorrectErrorBadges]: Going to recompute root=/tmp/patchery/src2, files in error=[file:/tmp/patchery/src2/A.java]. If you open the Task List after error badges have appeared but before opening any supposedly erroneous class, you can see e.g. cannot find symbol: variable Y location: class B File B.java Location patchery/src3 cannot find symbol: variable y location: class Y File B.java Location patchery/src3 incompatible types found: <nulltype> required: <int> File B.java Location patchery/src3 operator + cannot be applied to int,<any> File B.java Location patchery/src3
Created attachment 63190 [details] Test project
In my actual sources, the error badge autocorrection actually creates an infinite loop (the autocorrection doesn't work, and keeps being attempted): http://www.netbeans.org/issues/show_bug.cgi?id=136047 Unfortunately, I haven't managed to create a test case to reproduce this outside of using the entire sfdc (closed source) tree. However, there's a pretty good chance that eliminating the initial problem here will prevent the loop. Still, the fact that error badge autocorrection doesn't contain a guaranteed termination condition seems pretty bad.
The problem seems to be that there is a cyclic dependency (based on the queries results) between src2 and src2b: src2 depends on /tmp/patchery/build/clz2:/tmp/patchery/build/clz1 which maps to /tmp/patchery/src2:/tmp/patchery/src2b:/tmp/patchery/src1 src2b depends on /tmp/patchery/build/clz2:/tmp/patchery/build/clz1 which maps to /tmp/patchery/src2:/tmp/patchery/src2b:/tmp/patchery/src1 The source classpath of src2 does not contain src2b and vice versa, so these two source roots are not part of the same compilation unit. There is no reasonable order in which these two source roots should be compiled, so the order is undefined inside the IDE, which leads into semi-incorrect error badges. The source roots either needs to represent one compilation unit (i.e. have common source path) or it needs to be possible to order the source roots.
I'll see if that works. Basically what is wanted is for the following properties to be changed: /tmp/patchery/src2#source=/tmp/patchery/src2:/tmp/patchery/src2b /tmp/patchery/src2b#source=/tmp/patchery/src2:/tmp/patchery/src2b /tmp/patchery/src3#source=/tmp/patchery/src3:/tmp/patchery/src3b /tmp/patchery/src3b#source=/tmp/patchery/src3:/tmp/patchery/src3b
The use cases in our real source depot for this are all of the form "src" and "src-gen" compiling to the same "classes" dir. It is always the case that src-gen is compiled first, and uses as a basis for the src tree (an antlr-generated parser, for instance). Probably there are better ways to lay this out, but this is the way the ant script is written, and I'm not really in a position to change that.
Should be fixed in contrib #5ebf4711ac53 for this case at least; changing project to report src2 & src2b as one compilation unit, also src3 & src3b.