Scala Programming Language
  1. Scala Programming Language
  2. SI-4893

An error message based on a positionless symbol is useless and frustrating

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: Scala 2.9.0-1
    • Fix Version/s: None
    • Component/s: Misc Compiler
    • Labels:
      None
    • Environment:

      maven-compiler-plugin 2.3.2, maven-scala-plugin 2.15.2 , jdk 7 (but same issue with jdk6), ubuntu 11

      Description

      Hijacking original maven ticket to narrow it to the part I can do something about. The bug itself (as opposed to the poor error message) is SI-5504.

      – begin email
      % scalac b.scala
      error: type _$1 is defined twice
      one error found

      That's the whole message, even if I'm compiling 1000 files. (See SI-5504.) Separately from the bug, I'd like to fix the fact that this gives you zero hint where the problem is.

      Can someone tell me where the position is supposed to originate. Neither the _$1 type parameter(s) nor any their owners have any position. I can hack it to at least print the file by attaching context.unit to the message, but

      a) we don't want to hack the filename into error messages on a case by case basis
      b) the filename alone is pretty unimpressive, don't we have more granular information than that?

      Looking at ClassfileParser it seems only to record SourceFile when there is source code corresponding to the classfile being parsed. There must be some kind of audit trail which leads backward from a symbol to the classfile where it originated, and from there to at the least the name of a method or class, right? It would make things a lot easier for everyone (scala users and compiler debuggers alike) if there were.

      The nature of this bug - and most likely the remedy as well - would be self-apparent if the error message could simply print out from where these two ostensibly duplicate _$1s originated.

        Activity

        Hide
        Paul Phillips added a comment -

        Here you go!

        Show
        Paul Phillips added a comment - Here you go!
        Hide
        Paul Phillips added a comment -

        Well, I can now tell you what this is based on the error message alone. Don't use wildcards in package objects.

        Show
        Paul Phillips added a comment - Well, I can now tell you what this is based on the error message alone. Don't use wildcards in package objects.
        Hide
        Konstantine Kougios added a comment -

        Thanks Paul. Which package object and which wildcard? Also, can the compiler output the problematic source file name and maybe line number if applicable?

        Show
        Konstantine Kougios added a comment - Thanks Paul. Which package object and which wildcard? Also, can the compiler output the problematic source file name and maybe line number if applicable?

          People

          • Assignee:
            Josh Suereth
            Reporter:
            Konstantine Kougios
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:

              Development