Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8145466

javac: No line numbers in compilation error

    Details

    • Subcomponent:
    • Resolved In Build:
      b100
    • Verification:
      Verified

      Backports

        Description

        On 8u65/8u66, the attached Test class shows javac displaying an error but not displaying line numbers associated with the error.

        example output :

        $/java/re/jdk/9/promoted/all/b94/binaries/solaris-sparcv9/bin/javac Test.java
        error: incompatible types: possible lossy conversion from long to int
        Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
        1 error

        Would like the javac compiler to include a line number when it displays this error.

        1. Test.java
          3 kB
          Jonathan Gibbons

          Activity

          Hide
          jjg Jonathan Gibbons added a comment -
          In JDK 9, the message comes from Check.java checkType, c. line 565 (possible.loss.of.precision)
          Code is locally the same in jdk8u
          http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/file/0caab0d65a04/src/share/classes/com/sun/tools/javac/comp/Check.java#l550

          needs deeper investigation why pos is not set
          Show
          jjg Jonathan Gibbons added a comment - In JDK 9, the message comes from Check.java checkType, c. line 565 (possible.loss.of.precision) Code is locally the same in jdk8u http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/file/0caab0d65a04/src/share/classes/com/sun/tools/javac/comp/Check.java#l550 needs deeper investigation why pos is not set
          Hide
          jjg Jonathan Gibbons added a comment -
          Behavior verified in jdk9 with provided test case
          Show
          jjg Jonathan Gibbons added a comment - Behavior verified in jdk9 with provided test case
          Hide
          mcimadamore Maurizio Cimadamore added a comment -
          workaround: use the compiler flag -Xdiags:verbose.

          It's an issue in the error message simplification.
          Show
          mcimadamore Maurizio Cimadamore added a comment - workaround: use the compiler flag -Xdiags:verbose. It's an issue in the error message simplification.
          Hide
          mcimadamore Maurizio Cimadamore added a comment -
          The rewriteDiagnostic logic should be rewritten as follows (Resolve.java: 4183)

          @Override
                      public JCDiagnostic rewriteDiagnostic(JCDiagnostic.Factory diags,
                              DiagnosticPosition preferedPos, DiagnosticSource preferredSource,
                              DiagnosticType preferredKind, JCDiagnostic d) {
                          JCDiagnostic cause = (JCDiagnostic)d.getArgs()[causeIndex];
                          DiagnosticPosition pos = d.getDiagnosticPosition();
                          if (pos == null) {
                              pos = preferedPos;
                          }
                          return diags.create(preferredKind, preferredSource, pos,
                                  "prob.found.req", cause);
                      }

          That is - if the position attached to the fragment is null (which can happen in some method lookups), the preferred position should be used instead, rather than blindly using the diagnostic pos (which, if null, leads to current problem).
          Show
          mcimadamore Maurizio Cimadamore added a comment - The rewriteDiagnostic logic should be rewritten as follows (Resolve.java: 4183) @Override             public JCDiagnostic rewriteDiagnostic(JCDiagnostic.Factory diags,                     DiagnosticPosition preferedPos, DiagnosticSource preferredSource,                     DiagnosticType preferredKind, JCDiagnostic d) {                 JCDiagnostic cause = (JCDiagnostic)d.getArgs()[causeIndex];                 DiagnosticPosition pos = d.getDiagnosticPosition();                 if (pos == null) {                     pos = preferedPos;                 }                 return diags.create(preferredKind, preferredSource, pos,                         "prob.found.req", cause);             } That is - if the position attached to the fragment is null (which can happen in some method lookups), the preferred position should be used instead, rather than blindly using the diagnostic pos (which, if null, leads to current problem).
          Hide
          mcimadamore Maurizio Cimadamore added a comment -
          Simple test case:

          class Foo {
             void test() {
                new Object() {
                   void g() {
                      m(2L);
                   }
                };
             }

             void m(int i) { }
          }
          Show
          mcimadamore Maurizio Cimadamore added a comment - Simple test case: class Foo {    void test() {       new Object() {          void g() {             m(2L);          }       };    }    void m(int i) { } }
          Hide
          mcimadamore Maurizio Cimadamore added a comment - - edited
          Moe bad news; compiling this:

          class Bar {
             Bar(Object o) { }
          }

          class Foo {
             void test() {
                new Bar(null) {
                   void g() {
                      m(2L);
                   }
                };
             }

             void m(int i) { }
          }

          generates the following (wrong) message:

          Main.java:29: error: incompatible types: possible lossy conversion from long to int
                new Bar(null) {
                        ^
          Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
          1 error

          (note that the line in which the error is reported is wrong). Again the problem disappears when using -Xdiags:verbose)
          Show
          mcimadamore Maurizio Cimadamore added a comment - - edited Moe bad news; compiling this: class Bar {    Bar(Object o) { } } class Foo {    void test() {       new Bar(null) {          void g() {             m(2L);          }       };    }    void m(int i) { } } generates the following (wrong) message: Main.java:29: error: incompatible types: possible lossy conversion from long to int       new Bar(null) {               ^ Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output 1 error (note that the line in which the error is reported is wrong). Again the problem disappears when using -Xdiags:verbose)
          Hide
          sadayapalam Srikanth Adayapalam added a comment -
          A fix that passes all tests and passes code review is available. I am exploring
          whether a slightly better solution can be arrived at. We will take a call
          early next week on what will be the final fix.
          Show
          sadayapalam Srikanth Adayapalam added a comment - A fix that passes all tests and passes code review is available. I am exploring whether a slightly better solution can be arrived at. We will take a call early next week on what will be the final fix.
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bdbad16dd9ac
          User: sadayapalam
          Date: 2015-12-22 11:08:04 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/bdbad16dd9ac User: sadayapalam Date: 2015-12-22 11:08:04 +0000
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/bdbad16dd9ac
          User: lana
          Date: 2016-01-06 20:14:16 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/bdbad16dd9ac User: lana Date: 2016-01-06 20:14:16 +0000

            People

            • Assignee:
              sadayapalam Srikanth Adayapalam
              Reporter:
              shadowbug Shadow Bug
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: