Commits on Apr 13, 2012
Commits on Apr 12, 2012
  1. Fixed failing test.

    dragos committed Apr 12, 2012
  2. Merge pull request #89 from scala-ide/issue/implicit-preferences-1000962

    dragos committed Apr 12, 2012
    Issue/implicit preferences 1000962
  3. Looks like a good idea to protect ourselves from 'nulls' coming from …

    dragos committed Apr 12, 2012
    …the Java editors (happened more than once for me). No review.
  4. Added two more preferences for implicit conversions.

    dragos committed Apr 12, 2012
    * only highlight implicit conversions (not arguments) (on my default)
    * only highlight the first line in a multi-line annotation (off by default)
    Fixed #1000962.
  5. Merge pull request #87 from scala-ide/feature/scala-debugger-1000864

    skyluc committed Apr 12, 2012
    Initial commit of the Scala debugger #1000864
  6. Better preferences and defaults for implicit highlighting.

    dragos committed Apr 12, 2012
    - switched to dark green and underlined for highlighting annotations
    - added hyperlinks from the Implicits preferences to the Annotations page.
Commits on Apr 11, 2012
  1. Added a ``Open the Log`` menu item under the Scala menu

    dotta committed Apr 10, 2012
    I've made two changes to make the log easier to consult:
    * Added a ``Open the Log`` menu item under the Scala menu. Clicking
      on it will open the log file inside Eclipse (using a standard text
    * The dialog opened when clicking the ``Report A Bug`` menu item
      (which is also located under the Scala menu) now contains a link to
      open the log file.
    Hopefully, these changes will make it easier for a user to consult the
    log and provide potentially useful information when creating a bug report.
    Fixed #1000970.
  2. Fixed 2.10 compilation

    dotta committed Apr 11, 2012
    * ``TreeOps`` was moved between 2.9 and 2.10, which caused compilatio to fail
    with 2.10.
    * Ignoring test ``TypeTest.set_is_a_type``. Problem seems to be that
    ``sym.nameString`` returns a different text in 2.9 and 2.10. I'll investigate
    this in the next days.
  3. Created a custom Tree Traverser to traverse TypeTree nodes

    dotta committed Apr 11, 2012
    The available compiler's ``Traverser`` does not recurse inside ``TypeTree``
    nodes This is inconvenient as compiler's tree's type such as ``ExistentialTypeTree``
    are "hidden" inside ``TypeTree`` node. Therefore I have created a custom tree traverser
    ``TypeTreeTraverser`` that tries to traverse ``TypeTree`` nodes when possible.
    This makes the ``SafeSymbol.safeSymbol`` routine simpler as it does no longer need to unroll
    ``TypeTree`` nodes.
  4. Refactoring: Moving safeSymbol into its own ``SafeSymbol`` trait

    dotta committed Apr 10, 2012
    Ignoring tests for existential types
    Problem is that the compiler Tree created for an existential uses ``Ident`` AST nodes,
    which do not have a symbol. Hence, it is currently not possible to classify existentials correctly.
  5. Removed one source of quadratic behavior in semantic highlighting.

    dragos committed with dotta Apr 6, 2012
    Added debug timings, and replaced a call to `Map.mapValue` with `map`. The main reason is that `mapValue` does not cache any results, and in this case the resulting map is called thousands of times with the same key. See comment in code for the exact source of quadratic behavior. This shaves off a good couple of seconds when highlighting `Typers.scala` (>5000 loc) on my laptop.
  6. Minor refactoring

    dotta committed Apr 4, 2012
    Following Mirko's suggestion in @0e47749, using now
    ``sym.setter(sym.owner)`` for finding the setter of a getter.
  7. Corrected classification of ``var``s.

    dotta committed Apr 4, 2012
    A ``var`` that gets accessed through its getter (remember, a ``var`` gets
    always compiled into a getter and a setter by ``scalac`` - uniform access
    principle) must be classified as a variable (either TemplateVar or LocalVar).
    The difficulty is that when a ``var`` gets accessed through its getter, the
    symbol handle we have in the ``Tree`` is a ``MethodSymbol`` for the getter.
    Therefore, to decide if behind a getter sits a ``val`` or a ``var`` we need to
    check if the symbol's owner (i.e., the getter's owner) contains a setter method
    that matches the getters' name (this can be done using the compiler method
    Fixed #1000958.
  8. Ignoring tests that are currently failing.

    dotta committed Apr 3, 2012
    Here follows a description of the current main point of pain:
    * packages are sometimes tricky to color. The main reason I can see is that sometimes the associated symbol has a TransparentPosition (symbols with TransparentPositions are filtered during the classification)
    * types inside ``classOf`` are currently not correctly colored.
    * package object seem to be trycky.
    * Import statements are difficult to handle correctly in general.
  9. Coloring fully-qualified annotation's type with a single color (thoug…

    dotta committed Apr 2, 2012
    …h, it may be better to color only the type, and not the packages)
  10. Tree.namePosition can be called only on visible trees (i.e., trees wi…

    dotta committed Apr 2, 2012
    …th a RangePosition).
  11. Correctly categorize types that take type parameters.

    dotta committed Mar 30, 2012
    Fix #1000938.
  12. Correctly retrieving the symbol associated to an ``import`` clause.

    dotta committed Mar 29, 2012
    I believe you will agree that finding the *right* symbol it's a interesting
    challenge in the case of an ``import`` clause. In a nutshell, the only way to
    know whether the imported ``name`` is referencing a class is to check if the
    symbol associated to ``expr.tpe.member(name.toTypeName)`` actually ``exists``.
    If it doesn't then the ``name`` must be referencing a module.
    There is one more issue with the way we resolve ``import`` clause: we are not
    correctly manipulating clauses like ``import scala.Option._``. This still needs
    to be fixed.
  13. Semantic Highlighting symbols' classification should not skip synthetic

    dotta committed Mar 29, 2012
    In the attempt of optimizing semantic highlighting, synthetic symbols were
    being skipped. That seemed to be a valid optimization, since synthetic symbols
    are associated to compiler injected definitions (which are hence not visible in
    the source code). However, user code may be use the synthetic definitions, and
    therefore it is not safe to filter away synthetic symbols during
    For instance, in the following example
    case class CaseClass(n: Int) {
        CaseClass(42) // <- this reference the companion object, which is a synthetic symbol
    ``CaseClass(42)`` is actually referencing the companion object of the class
    ``CaseClass``. The companion object has not been declared in the source, hence
    it is injected by the compiler, and a synthetic symbol will be used to
    reference it.
    On the other hand, it looks safe to skip anonymous function's symbols.
  14. Minor refactoring: Added a ``SemanticAction`` pure interface implemen…

    dotta committed Apr 4, 2012
    …ted by the
    semantic action classes.
  15. minor refactoring

    dotta committed Mar 28, 2012
  16. Turned ``SemanticHighlightingReconciliation`` into a class and using …

    dotta committed Apr 4, 2012
    …``java.util.concurrent.ConcurrentHashMap`` in place of Scala ``SynchronizedMap``.
  17. Minor refactoring in ``SymbolClassification`` and ``SymbolTests``

    dotta committed Apr 4, 2012
    The ``Selections`` trait was mixed-in to get access to the methods in
    ``PimpedTrees`` (which ``Selections`` mixes-in). Hence, I removed the
    ``Selections`` trait and mixed-in ``PimpedTrees``, which is all
    ``SymbolClassification`` class really needs.
  18. Optimization: Reduce number of time a Scala source is marked as changed

    dotta committed Apr 4, 2012
    Marking a Scala source as changed may trigger reconciliation, which can
    be a costly operation at this time since as the semantic actions are run
    in the reconciler thread.
    More importantly, a source should be marked as changed only if some change
    really occurred, that's why we now check if the source's ``delta`` has the
    flag ``IJavaElementDelta.F_CONTENT`` set.
  19. Try to minimize the number of symbols that are selected for highlight…

    dragos committed with dotta Mar 21, 2012
    …ing. Made safe the SymbolTest class (companionClass is not thread-safe).