Open scabug opened 13 years ago
Imported From: https://issues.scala-lang.org/browse/SI-4893?orig=1 Reporter: Konstantine Kougios (ariskk) Affected Versions: 2.9.0-1 See #5504 Attachments:
@paulp said: Here you go!
@paulp said: Well, I can now tell you what this is based on the error message alone. Don't use wildcards in package objects.
Konstantine Kougios (ariskk) said: Thanks Paul. Which package object and which wildcard? Also, can the compiler output the problematic source file name and maybe line number if applicable?
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 #5504.
That's the whole message, even if I'm compiling 1000 files. (See #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.