- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
error messages / position help
Sun, 2012-02-19, 19:09
% scalac b.scala error: type _$1 is defined twiceone 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.
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.
Sun, 2012-02-19, 20:11
#2
Re: error messages / position help
On Sun, Feb 19, 2012 at 10:49 AM, martin odersky <martin.odersky@epfl.ch> wrote:
Have you compiled with -Ydebug? I am asking because its seems we
currently swallow some errors that never get reported. If you get a
better error with -Ydebug, then you were bitten by this. It's due to
the changes to error handling that got checked in some weeks ago. I
have talked with Hubert about a slightly different architecture which
should fix these things for good.
Well, having looked at where the error message is created, I know I do get a better message with -Ydebug, but it does so by printing context.unit. Is the new architecture going to let me figure out from the symbol for _$1 that it originated with classfile foo/package$.class in the return type of method bar, without any scala source code being available? That's what I'm after.
Sun, 2012-02-19, 20:31
#3
Re: error messages / position help
On Sun, Feb 19, 2012 at 10:49 AM, martin odersky <martin.odersky@epfl.ch> wrote:
Have you compiled with -Ydebug? I am asking because its seems we
currently swallow some errors that never get reported. If you get a
better error with -Ydebug, then you were bitten by this.
The other thing is that the message is equally informative in 2.9.1, so it can't be due to a change from a few weeks ago.
% scalac29 a.scala % scalac29 b.scala error: type _$1 is defined twiceone error found
Sun, 2012-02-19, 20:41
#4
Re: error messages / position help
On Sun, Feb 19, 2012 at 11:22 AM, Paul Phillips <paulp@improving.org> wrote:
The other thing is that the message is equally informative in 2.9.1, so it can't be due to a change from a few weeks ago.
For that matter, the error message is the same in 2.8.0. So it's as old as package objects.
Sun, 2012-02-19, 20:51
#5
Re: error messages / position help
On 02/19/2012 07:49 PM, martin odersky wrote:
> Have you compiled with -Ydebug? I am asking because its seems we
> currently swallow some errors that never get reported. If you get a
> better error with -Ydebug, then you were bitten by this. It's due to
> the changes to error handling that got checked in some weeks ago. I
> have talked with Hubert about a slightly different architecture which
> should fix these things for good.
Errors are no longer swallowed, I fixed that yesterday.
As Paul mentioned this problem already existed for some time so it is
not related to my commits.
hubert
> Cheers
>
> -- Martin
>
> On Sun, Feb 19, 2012 at 7:09 PM, Paul Phillips wrote:
>> % 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.
>>
>
>
Sun, 2012-02-19, 21:01
#6
Re: error messages / position help
On 02/19/2012 08:04 PM, Paul Phillips wrote:
If it wasn't possible before then I doubt it will be easy. You can temporarily assign it to me and I will have a look at it next week.
hubert
5Z8C2uDjxorkNHoFiJmL4Zw [at] mail [dot] gmail [dot] com" type="cite">
On Sun, Feb 19, 2012 at 10:49 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch" rel="nofollow">martin.odersky@epfl.ch> wrote:
Have you compiled with -Ydebug? I am asking because its seems we
currently swallow some errors that never get reported. If you get a
better error with -Ydebug, then you were bitten by this. It's due to
the changes to error handling that got checked in some weeks ago. I
have talked with Hubert about a slightly different architecture which
should fix these things for good.
Well, having looked at where the error message is created, I know I do get a better message with -Ydebug, but it does so by printing context.unit. Is the new architecture going to let me figure out from the symbol for _$1 that it originated with classfile foo/package$.class in the return type of method bar, without any scala source code being available? That's what I'm after.
If it wasn't possible before then I doubt it will be easy. You can temporarily assign it to me and I will have a look at it next week.
hubert
Sun, 2012-02-19, 21:11
#7
Re: error messages / position help
On Sun, Feb 19, 2012 at 11:52 AM, Hubert Plociniczak <hubert.plociniczak@epfl.ch> wrote:
If it wasn't possible before then I doubt it will be easy. You can temporarily assign it to me and I will have a look at it next week.
I'll hang onto it, but I need information to proceed (that's why I took the highly unusual step of generating communication.) To wit, is there any part of what I described which is already supposed to work, or which overlaps with some existing mechanism for positioning things? And why shouldn't I make a symbol's SourceFile refer to the classfile from which it was read if there is no source file available; at least then we're not in a total information vacuum. Right now such a sourcefile is just null. It's not like the slot is going to good use.
Mon, 2012-02-20, 09:31
#8
Re: error messages / position help
On 02/19/2012 09:00 PM, Paul Phillips wrote:
I agree that having such info would be useful. But then storing it in SourceFile is not correct, right? I'm guessing here but maybe tools like IDE rely on that information pointing to the right file.
CAEaELhSJwnyiaVVMGoKEm0Bzv0FpDSTubuk645jiPPTxm7GCwQ [at] mail [dot] gmail [dot] com" type="cite">
On Sun, Feb 19, 2012 at 11:52 AM, Hubert Plociniczak <hubert [dot] plociniczak [at] epfl [dot] ch" rel="nofollow">hubert.plociniczak@epfl.ch> wrote:
If it wasn't possible before then I doubt it will be easy. You can temporarily assign it to me and I will have a look at it next week.
I'll hang onto it, but I need information to proceed (that's why I took the highly unusual step of generating communication.) To wit, is there any part of what I described which is already supposed to work, or which overlaps with some existing mechanism for positioning things? And why shouldn't I make a symbol's SourceFile refer to the classfile from which it was read if there is no source file available; at least then we're not in a total information vacuum. Right now such a sourcefile is just null. It's not like the slot is going to good use.
I agree that having such info would be useful. But then storing it in SourceFile is not correct, right? I'm guessing here but maybe tools like IDE rely on that information pointing to the right file.
Mon, 2012-02-20, 11:01
#9
Re: error messages / position help
On Mon, Feb 20, 2012 at 9:25 AM, Hubert Plociniczak
wrote:
> On 02/19/2012 09:00 PM, Paul Phillips wrote:
>
>
>
> On Sun, Feb 19, 2012 at 11:52 AM, Hubert Plociniczak
> wrote:
>>
>> If it wasn't possible before then I doubt it will be easy. You can
>> temporarily assign it to me and I will have a look at it next week.
>
>
> I'll hang onto it, but I need information to proceed (that's why I took the
> highly unusual step of generating communication.) To wit, is there any
> part of what I described which is already supposed to work, or which
> overlaps with some existing mechanism for positioning things? And why
> shouldn't I make a symbol's SourceFile refer to the classfile from which it
> was read if there is no source file available; at least then we're not in a
> total information vacuum. Right now such a sourcefile is just null. It's
> not like the slot is going to good use.
>
>
> I agree that having such info would be useful. But then storing it in
> SourceFile is not correct, right? I'm guessing here but maybe tools like IDE
> rely on that information pointing to the right file.
Yes, we change Sourcefile behavior.
Have you compiled with -Ydebug? I am asking because its seems we
currently swallow some errors that never get reported. If you get a
better error with -Ydebug, then you were bitten by this. It's due to
the changes to error handling that got checked in some weeks ago. I
have talked with Hubert about a slightly different architecture which
should fix these things for good.
Cheers