- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Tracking down an error
Mon, 2009-12-07, 14:17
I'm getting this from the compiler:
Exception in thread "main" java.lang.Error: no-symbol does not have owner at scala.tools.nsc.symtab.Symbols$NoSymbol$.owner(Symbols.scala:2029) at scala.tools.nsc.transform.LambdaLift$LambdaLifter.outer(LambdaLift.scala:75) at scala.tools.nsc.transform.LambdaLift$LambdaLifter.scala$tools$nsc$transform$LambdaLift$LambdaLifter$$enclMethOrClass(LambdaLift.scala:106) at scala.tools.nsc.transform.LambdaLift$LambdaLifter.searchIn$1(LambdaLift.scala:286) at scala.tools.nsc.transform.LambdaLift$LambdaLifter.proxy(LambdaLift.scala:299) at scala.tools.nsc.transform.LambdaLift$LambdaLifter.proxyRef(LambdaLift.scala:315) at scala.tools.nsc.transform.LambdaLift$LambdaLifter.postTransform(LambdaLift.scala:393) at scala.tools.nsc.transform.LambdaLift$LambdaLifter.transform(LambdaLift.scala:409) at scala.tools.nsc.ast.Trees$Transformer$$anonfun$transformTrees$1.apply(Trees.scala:1554) at scala.tools.nsc.ast.Trees$Transformer$$anonfun$transformTrees$1.apply(Trees.scala:1554)
Now I *know* that it's related to code I synthesized in an earlier phase, but I did a full AST dump after that and everything seems to be in order. What I'd like is a way to have the compiler perform inform me of the errored compilation unit and AST fragment when such exceptions are thrown, but can't figure a suitable combination of settings that will do this.
-Ylog:lambdalift is the obvious one, but doesn't generate any output at all-Ydebug was another, but that gave me totally different errors!
I also tried the eclipse debugger, but that's not so happy dealing with scala symbols right now.
All suggestions gratefully accepted...
Exception in thread "main" java.lang.Error: no-symbol does not have owner at scala.tools.nsc.symtab.Symbols$NoSymbol$.owner(Symbols.scala:2029) at scala.tools.nsc.transform.LambdaLift$LambdaLifter.outer(LambdaLift.scala:75) at scala.tools.nsc.transform.LambdaLift$LambdaLifter.scala$tools$nsc$transform$LambdaLift$LambdaLifter$$enclMethOrClass(LambdaLift.scala:106) at scala.tools.nsc.transform.LambdaLift$LambdaLifter.searchIn$1(LambdaLift.scala:286) at scala.tools.nsc.transform.LambdaLift$LambdaLifter.proxy(LambdaLift.scala:299) at scala.tools.nsc.transform.LambdaLift$LambdaLifter.proxyRef(LambdaLift.scala:315) at scala.tools.nsc.transform.LambdaLift$LambdaLifter.postTransform(LambdaLift.scala:393) at scala.tools.nsc.transform.LambdaLift$LambdaLifter.transform(LambdaLift.scala:409) at scala.tools.nsc.ast.Trees$Transformer$$anonfun$transformTrees$1.apply(Trees.scala:1554) at scala.tools.nsc.ast.Trees$Transformer$$anonfun$transformTrees$1.apply(Trees.scala:1554)
Now I *know* that it's related to code I synthesized in an earlier phase, but I did a full AST dump after that and everything seems to be in order. What I'd like is a way to have the compiler perform inform me of the errored compilation unit and AST fragment when such exceptions are thrown, but can't figure a suitable combination of settings that will do this.
-Ylog:lambdalift is the obvious one, but doesn't generate any output at all-Ydebug was another, but that gave me totally different errors!
I also tried the eclipse debugger, but that's not so happy dealing with scala symbols right now.
All suggestions gratefully accepted...
Mon, 2009-12-07, 15:47
#2
Re: Tracking down an error
On Mon, Dec 07, 2009 at 03:13:19PM +0100, Miguel Garcia wrote:
> About -Ycheck, I haven't used it a lot, so I can't comment. But in
> case this helps, using -Ypmatdebug makes the compiler fail at a later
> phase (probably because it mutates the trees). At least for the
> example program I compiled :-)
I'm always surprised to hear about anyone else finding my secret -Y
options. Yes, -Ypmat-debug is very breaky at the moment.
Mon, 2009-12-07, 15:57
#3
Re: Tracking down an error
-Ycheck is also being very obscure:
.\src\main\scala\autoproxy\test\Main.scala:1: error: **** ERROR DURING INTERNAL CHECKING **** package test has wrong owner: package autoproxy, should be: package <root>package autoproxy.test ^
Why should it be <root>? I don't want it to be <root>!I'm perfectly happy where I chose to put it, thank you very much.
On Mon, Dec 7, 2009 at 2:39 PM, Paul Phillips <paulp@improving.org> wrote:
.\src\main\scala\autoproxy\test\Main.scala:1: error: **** ERROR DURING INTERNAL CHECKING **** package test has wrong owner: package autoproxy, should be: package <root>package autoproxy.test ^
Why should it be <root>? I don't want it to be <root>!I'm perfectly happy where I chose to put it, thank you very much.
On Mon, Dec 7, 2009 at 2:39 PM, Paul Phillips <paulp@improving.org> wrote:
On Mon, Dec 07, 2009 at 03:13:19PM +0100, Miguel Garcia wrote:
> About -Ycheck, I haven't used it a lot, so I can't comment. But in
> case this helps, using -Ypmatdebug makes the compiler fail at a later
> phase (probably because it mutates the trees). At least for the
> example program I compiled :-)
I'm always surprised to hear about anyone else finding my secret -Y
options. Yes, -Ypmat-debug is very breaky at the moment.
--
Paul Phillips | It's not enough to bash in heads - you've got to
Future Perfect | bash in minds.
Empiricist | -- Capt Hammer
all hip pupils! |----------* http://www.improving.org/paulp/ *----------
Kevin,
From the descriptions in Settings.scala, -Ycheck seems the right tool for
the job ("Check the tree at the end of the given phase. Specify "all" to
check all checkable phases")
Debugging or not, -Ycheck or not, it would be useful to know the expected
invariants for ASTs in different phases, i.e. the static semantics of the
language fragment at that phase. Some of those invariants, right after
typer, can be gleaned from scala.tools.nsc.typechecker.RefChecks
About -Ycheck, I haven't used it a lot, so I can't comment. But in case this
helps, using -Ypmatdebug makes the compiler fail at a later phase (probably
because it mutates the trees). At least for the example program I compiled
:-)
Miguel
http://www.sts.tu-harburg.de/people/mi.garcia