Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Apr 13, 2012
  1. @dotta
  2. @dotta
Commits on Apr 12, 2012
  1. @dragos

    Fixed failing test.

    dragos authored
  2. @dragos

    Merge pull request #89 from scala-ide/issue/implicit-preferences-1000962

    dragos authored
    Issue/implicit preferences 1000962
  3. @skyluc
  4. @dragos

    Looks like a good idea to protect ourselves from 'nulls' coming from …

    dragos authored
    …the Java editors (happened more than once for me). No review.
  5. @skyluc
  6. @dragos
  7. @dragos

    Added two more preferences for implicit conversions.

    dragos authored
    * only highlight implicit conversions (not arguments) (on my default)
    * only highlight the first line in a multi-line annotation (off by default)
    
    Fixed #1000962.
  8. @skyluc

    Merge pull request #87 from scala-ide/feature/scala-debugger-1000864

    skyluc authored
    Initial commit of the Scala debugger #1000864
  9. @dragos

    Better preferences and defaults for implicit highlighting.

    dragos authored
    - 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. @dotta

    Added a ``Open the Log`` menu item under the Scala menu

    dotta authored
    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
      editor).
    
    * 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. @dotta

    Fixed 2.10 compilation

    dotta authored
    * ``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. @dotta

    Created a custom Tree Traverser to traverse TypeTree nodes

    dotta authored
    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. @dotta

    Refactoring: Moving safeSymbol into its own ``SafeSymbol`` trait

    dotta authored
    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. @dotta
  6. @dragos @dotta

    Removed one source of quadratic behavior in semantic highlighting.

    dragos authored dotta committed
    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.
  7. @dotta

    Minor refactoring

    dotta authored
    Following Mirko's suggestion in @0e47749, using now
    ``sym.setter(sym.owner)`` for finding the setter of a getter.
  8. @dotta

    Corrected classification of ``var``s.

    dotta authored
    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
    ``nme.getterToSetter``).
    
    Fixed #1000958.
  9. @dotta

    Ignoring tests that are currently failing.

    dotta authored
    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.
  10. @dotta
  11. @dotta
  12. @dotta

    Coloring fully-qualified annotation's type with a single color (thoug…

    dotta authored
    …h, it may be better to color only the type, and not the packages)
  13. @dotta
  14. @dotta
  15. @dotta
  16. @dotta

    Correctly retrieving the symbol associated to an ``import`` clause.

    dotta authored
    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.
  17. @dotta

    Semantic Highlighting symbols' classification should not skip synthetic

    dotta authored
    symbols.
    
    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
    classification.
    
    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.
  18. @dotta

    Minor refactoring: Added a ``SemanticAction`` pure interface implemen…

    dotta authored
    …ted by the
    
    semantic action classes.
  19. @dotta

    minor refactoring

    dotta authored
  20. @dotta
  21. @dotta

    Turned ``SemanticHighlightingReconciliation`` into a class and using …

    dotta authored
    …``java.util.concurrent.ConcurrentHashMap`` in place of Scala ``SynchronizedMap``.
  22. @dotta

    Minor refactoring in ``SymbolClassification`` and ``SymbolTests``

    dotta authored
    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.
  23. @dotta

    Optimization: Reduce number of time a Scala source is marked as changed

    dotta authored
    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.
  24. @dragos @dotta

    Try to minimize the number of symbols that are selected for highlight…

    dragos authored dotta committed
    …ing. Made safe the SymbolTest class (companionClass is not thread-safe).
Something went wrong with that request. Please try again.