#1001304
- Created on2012-11-01 13:10
- Reported by
- StatusFixed
- PriorityNormal (3)
- Assigned to
- Milestone
- Plan Level-
- Due Date-
no-symbol does not have an owner
scala.reflect.internal.FatalError: no-symbol does not have an owner
at scala.reflect.internal.SymbolTable.abort(SymbolTable.scala:48)
at scala.tools.nsc.Global.abort(Global.scala:253)
at scala.reflect.internal.Symbols$NoSymbol.owner(Symbols.scala:3193)
at scala.tools.eclipse.launching.ScalaLaunchShortcut$$anonfun$1.scala$tools$eclipse$launching$ScalaLaunchShortcut$$anonfun$$isTopLevelClass$1(ScalaLaunchShortcut.scala:170)
at scala.tools.eclipse.launching.ScalaLaunchShortcut$$anonfun$1$$anonfun$apply$2.apply(ScalaLaunchShortcut.scala:195)
at scala.tools.eclipse.launching.ScalaLaunchShortcut$$anonfun$1$$anonfun$apply$2.apply(ScalaLaunchShortcut.scala:194)I'm putting this in M3 because I consider it should be quick to fix.
Leave a comment
(In scala-ide:76c1c881bd464d0c72d43aba8191573340902aab) Fixed #1001304 - NSDHO when hovering the Scala launch shortcut
When checking if a runnable JUnit test class is available in the compilation
unit containing the selected code element, it is sometime possible to get a
Scala compiler exception: ``No symbol does not have an owner``. This happens
when trying to access the ``owner`` member of a ``Symbol`` that is of type
``NoSymbol``.
I'm unfortunately not sure on the whys this can happen, but the net result is
particularly bad. The pragmatic solution is to check that the ``symbol`` is a
``ClassSymbol``, and simply bail out when it isn't.
No test is available because we honestly have no clue about how to reproduce
this.
Branch: master
When checking if a runnable JUnit test class is available in the compilation
unit containing the selected code element, it is sometime possible to get a
Scala compiler exception: ``No symbol does not have an owner``. This happens
when trying to access the ``owner`` member of a ``Symbol`` that is of type
``NoSymbol``.
I'm unfortunately not sure on the whys this can happen, but the net result is
particularly bad. The pragmatic solution is to check that the ``symbol`` is a
``ClassSymbol``, and simply bail out when it isn't.
No test is available because we honestly have no clue about how to reproduce
this.
Branch: master
on 2012-12-13 15:52 *
By Mirco Dotta
(In scala-ide:1891f62e2ce92f15591b4e9a5472b392a6c8f1d7) Show Run As > JUnit Test when right clicking on a source that contains runnable
JUnit Test classes
If a source is closed (i.e., it hasn't been typechecked yet - this is
important!) and, through the package explorer, you right click and select Run
As, no "JUnit Test" option used to be shown.
The problem was that if the source is not opened (and typechecked), the
``@Test`` annotation can only be found in the AST, and not in the symbol. The
fix is to always initialize the member's symbol before looking if it declares
the ``@Test`` annotation. By doing so, the ``@Test`` annotation is found also
for members inherited from a superclass or a trait!
In this commit I've also implemented the missing logic for considering the
JUnit4 ``@RunWith`` annotation. Basically, if a class or any of its inherited
types specify the ``@RunWith`` annotation, then the class is a valid,
runnable, JUnit4 test class.
As part of this commit I've also made some improvements to the existing testing
class (formerly named ``LaunchableTesters``, now splitted into two distinct
classes: ``MainMethodFinderTest`` and ``RunAsTest``).
The work on these tickets (Re #1001379, Re #1001380) was somewhat motivated by
(or a consequence of) Re #1001304 and Re #1001275.
Finally, I'm quite convinced that the ``ScalaLaunchShortcut.getMainMethods``
could use some similar love, but this should be done in a separate PR(there is
already enough meat here).
Fix #1001234, Fix #1001379, Fix #1001380 and Fix #1000731.
Branch: master
JUnit Test classes
If a source is closed (i.e., it hasn't been typechecked yet - this is
important!) and, through the package explorer, you right click and select Run
As, no "JUnit Test" option used to be shown.
The problem was that if the source is not opened (and typechecked), the
``@Test`` annotation can only be found in the AST, and not in the symbol. The
fix is to always initialize the member's symbol before looking if it declares
the ``@Test`` annotation. By doing so, the ``@Test`` annotation is found also
for members inherited from a superclass or a trait!
In this commit I've also implemented the missing logic for considering the
JUnit4 ``@RunWith`` annotation. Basically, if a class or any of its inherited
types specify the ``@RunWith`` annotation, then the class is a valid,
runnable, JUnit4 test class.
As part of this commit I've also made some improvements to the existing testing
class (formerly named ``LaunchableTesters``, now splitted into two distinct
classes: ``MainMethodFinderTest`` and ``RunAsTest``).
The work on these tickets (Re #1001379, Re #1001380) was somewhat motivated by
(or a consequence of) Re #1001304 and Re #1001275.
Finally, I'm quite convinced that the ``ScalaLaunchShortcut.getMainMethods``
could use some similar love, but this should be done in a separate PR(there is
already enough meat here).
Fix #1001234, Fix #1001379, Fix #1001380 and Fix #1000731.
Branch: master