``sbt.precompiled.version`` has to match ``scala.version``
It is really important that when we build the IDE, the sbt artifacts are compiled against the exact same Scala compiler that is shipped in the IDE. To this end, I've updated the value of ``sbt.precompiled.version`` to always match the ``scala.version`` one. This is needed because while the Scala library is ensured to be forward binary compatible across minor releases, no such guarantee is provided for the Scala compiler (and the Sbt compiler-interface, which we use in the IDE, does need to be linked against the Scala compiler). As part of this commit, I've also made another small change to the property ``scala.major.minor.version`` and renamed it ``scala.era.major.version``, as this what this property actually contains.
Add URL hyperlink detector
The URL hyperlink detector shows hyperlinks for URLs in comments as well as strings. Because the detector is functionality already built into the Eclipse API, no tests are created. Fix #1001266
Implemented JUnit test finder logic in Scala.
Works for both Scala and Java sources, and adds a 'Scala JUnit' test kind and shortcut for 'Run As'. We hook this test finder using an internal extension point defined by `org.eclipse.jdt.junit.core`, `internal_testkinds`. This class is used both when right-clicking on a Java element and choosing "Run As - Scala JUnit test" and when hitting the "Search" button in the JUnit Run configuration dialog. Alternatives were considered, but not pursued: * AspectJ to hook into the JUnit runner. Discarded as hackish, not future-proof and the risk of breaking the plain JDT plugin * implement a Scala JUnit configuration type, but that would duplicate more of the JUnit configuration type and involved rewriting dialogs and buttons Fixed #1001275, Fixed #1000782.
We welcome Simon as an official member of the Scala IDE Team. It's a real pleasure to have him in the team. This is our way to say *thank you* for the marvelous work you have been doing in the past 6 months. Keep up the good work!
Show implicit arguments in the quick fix for implicit highlighting.
`hasSymbol` is a misleading name: `TypeApply` nodes return false, though they definitely have a symbol. Changed the condition to filter on actually having a symbol. Fixed #1001280.
…s 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.
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.
…-1001391 Tweak the tests to workaround defect.
On Linux, additional inaccurate matches are returned in the 2 updated tests (see #1001392). Tweaked the test data to avoid being in this case. Fix #1001391
Logical structure works on 2.10
…1001381 Avoid race condition in renaming by running on the PC thread.
Added a version checker. Added logical structure tests. Added methods to the Scala debug model to: * get handle to objects and classes * get field value on classes and static classes * invoke methods on classes and static classes
Fixed the build for Juno.
The build was broken because Juno changed an interface method from taking a raw type to using a proper type, like this: connect(Map args, ..) to connect(Map<String, String> args, ..) We used to implement this method by using an existential type, but overriding rules prevent it in the new case. So we resort to Java, where we bridge the method in question towards one that has the proper generic type signature in both Indigo and Juno. Fixed #1001374.
Fixed #1001376 - Race condition in the indexer (i.e., ``ScalaIndexBuilder``)
Upgraded to the latest release version of AspectJ weaving.
…1202 Fix #1001202 - Unable to set breakpoint in source attachment
It turns out that setting a breakpoint on a module declaration could sometime fail badly (an error dialog was displayed to the user). The reason why this fails is really simple, a call to ``CompilationUnitAdapter.getPackageDeclarations`` is performed while trying to toggle the line breakpoint in the editor. And, because the existing implementation of ``CompilationUnitAdapter.getPackageDeclarations`` used to throw an ``UnsupportedOperationException``, it's not a surpise that this used to fail badly. The quick fix was to implement that method so that the ``PackageDeclaration`` for the opened classfile source is returned. And, in the specific case, the ``PackageDeclaration`` is only needed to find the raw package name, which is why I have only implemented the ``getElementName`` (look at ``ToggleBreakpointAdapter.createQualifiedTypeName``, at some point you will see a call to ``pd.getElementName();``, where ``pd`` is the ``PackageDeclaration``). This seems to be enough for fixing this specific issue, and all considered, this fix can only improve on the status quo (simply because the former implementation thrown an exception right away). This PR doesn't come with test because the functionality is in the editor, and we currently don't have a way to create UI tests. That said, the whole logic we use to handle classfile sources looks a bit broken. First, why do we need ``ScalaClassFile`` to extend ``ScalaCompilationUnit``? That does not quite make sense to me. And the fact that the JDT ``ClassFile`` does not extend the JDT ``ICompilationUnit`` just give one more indication that this is likely not needed. And, if we could make ``ScalaClassFile`` not to extends ``ScalaCompilationUnit``, we could then get rid of the ``CompilationUnitAdapter``. I've been spending a bit of time looking into this, but unfortunately I don't have time to experiment this any further at the moment. I've pushed what I have [here](https://github.com/dotta/scala-ide/tree/wip/classfile-not-a-compilation-unit), it's not clean but it should give an idea of where I am heading with this (and hopefully I'll work on this during my spare time some time in the future).
Issue/fix tcpipspy on mac
Don't reuse a MarkOccurrences index if the global instance is not curren...
Small refactoring in ``ScalaThread``
* Renamed ``ScalaThread.thread`` into ``ScalaThread.threadRef`` * No need to pass the ``threadRef`` to the ``ScalaThreadActor`` constructor.