[NETBEANS-7981] Handling Diagnostics with position -1 while writing error/warning index.

[lahodaj]

When code like:

package javaapplication2;

public class JavaApplication2 {

    public static void main(String[] args) {
        new G() {
            
        };
    }
    
}

class G {
    @Deprecated
    G() {}
}

is indexed with -Xlint:deprecation, writing error/warning index may fail due to an exception like:

java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 605
	at com.sun.tools.javac.util.Position$LineTabMapImpl.getColumnNumber(Position.java:266)
	at com.sun.tools.javac.util.Position$LineMapImpl.getColumnNumber(Position.java:236)
	at com.sun.tools.javac.util.Position$LineTabMapImpl.getColumnNumber(Position.java:253)
	at org.netbeans.modules.java.source.indexing.JavaCustomIndexer$ErrorConvertorImpl.getRange(JavaCustomIndexer.java:1329)

This is because the Diagnostics has end position -1. This patch simply proposes to treat this case as a missing end position.

Separately, it should be investigated if javac should produce errors or warnings like this.

[matthiasblaesing]

The warnings that cause this for the sample case @mbien described are:

"NodesAnnotationProcessor.java:119: Warnung: [deprecation] SimpleAnnotationValueVisitor6() in javax.lang.model.util.SimpleAnnotationValueVisitor6 ist veraltet
                    String clsName = type.accept(new SimpleAnnotationValueVisitor6<String, Object>() {
                                                                                                     ^"
                                                                                                     
"NodesAnnotationProcessor.java:119: Warnung: [deprecation] SimpleAnnotationValueVisitor6() in javax.lang.model.util.SimpleAnnotationValueVisitor6 ist veraltet
                    String clsName = type.accept(new SimpleAnnotationValueVisitor6<String, Object>() {
                                                                                                     ^"

"NBClassReader.java:123: Warnung: [unchecked] Nicht geprüfter Aufruf von ForwardingJavaFileObject(F) als Mitglied des Raw-Typs javax.tools.ForwardingJavaFileObject
                            c.classfile = new ForwardingJavaFileObject(origFile) {
                                                                                 ^"

"JavaHintsAnnotationProcessor.java:142: Warnung: [deprecation] ElementScanner6() in javax.lang.model.util.ElementScanner6 ist veraltet
            new ElementScanner6<Void, Void>() {
                                              ^"

"TestBase.java:409: Warnung: [deprecation] MIMEResolver() in org.openide.filesystems.MIMEResolver ist veraltet
    static class MIMEResolverImpl extends MIMEResolver {
           ^"

For these cases the new code path is hit, so from my POV this fixes the issue. Thank you.

[mbien]

adding the file location to the message might help in future to track problems down:

diff --git a/ide/parsing.indexing/src/org/netbeans/modules/parsing/impl/indexing/errors/TaskCache.java b/ide/parsing.indexing/src/org/netbeans/modules/parsing/impl/indexing/errors/TaskCache.java
index 08a415f..95d128a 100644
--- a/ide/parsing.indexing/src/org/netbeans/modules/parsing/impl/indexing/errors/TaskCache.java
+++ b/ide/parsing.indexing/src/org/netbeans/modules/parsing/impl/indexing/errors/TaskCache.java
@@ -229,7 +229,7 @@
                 }
             });
         } catch (IOException ex) {
-            Exceptions.printStackTrace(ex);
+            LOG.log(Level.SEVERE, "can't dump errors for: " + String.valueOf(i), ex);
         }
     }

It might be better to wrap + rethrow as runtime exception and let the indexer handle it - but this would go beyond a hotfix.

[dbalek]

Thanks.

[ebarboni]

I merge as it is ? and @mbien patch is for NB25 ?

[mbien]

I merge as it is ? and @mbien patch is for NB25 ?

@ebarboni I think it would be good to have better logging there. Since the exception does not tell where the problem is. In my case: i had probably about 100 projects open and had to narrow it down first. A good log line would point to the right place right away.

I suppose I could a) open a second PR or b) add a commit to this PR? cc @lahodaj @matthiasblaesing

[matthiasblaesing]

I think this is good to go as is. The exception backtrace is a 100% match into the right file. While I agree, that knowing the problematic file, this is IMHO not really needed for this hotfix.

[mbien]

I think this is good to go as is. The exception backtrace is a 100% match into the right file. While I agree, that knowing the problematic file, this is IMHO not really needed for this hotfix.

the exception trace won't contain the file path which is causing the exception. To clarify the diff: the i is the Indexable method parameter. i.toString() would provide the path - this is no index or anything like that.

[matthiasblaesing]

My focus is to get a new VC fast. We can discuss this longer, but from my perspective we gain little. I don't care either way. The fix is here and is mergeable, everything else takes more time.

[lahodaj]

I've tweaked the code to attach the message to the exception.

[ebarboni]

rc4 online