Permalink
Commits on Feb 25, 2013
  1. Merge pull request #333 from dotta/backport/3.0.0/cannot-enable-conti…

    dotta committed Feb 25, 2013
    …nuations-plugin-1001030
    
    Backport/3.0.0/cannot enable continuations plugin 1001030
  2. Testing presentation compiler when project depends on continuations.jar

    dotta committed Feb 25, 2013
    Added a couple of tests for making sure that the build compiler and the
    presentation compiler behave the same when compiling projects that depend on
    the continuations plugin.
    (cherry picked from commit 514c2a5)
  3. Do not force default location of -XpluginsDir in Scala Compiler Prefe…

    dotta committed Feb 24, 2013
    …rences
    
    Trying to force the default location to the plugins directory containing the
    continuations.jar plugin turned out to be a very bad idea (this was done as
    part of commit SHA-cbfd82d874f998b7726fec895ad4d83194ad1e5b).
    
    The issue is that the default location where the continuations.jar is stored
    changes *each time a user updates the Scala IDE* and, when updating, the
    *former location is deleted*. The net effect of this is that after upgrading,
    all projects using the continuations plugin would report the following error
    
    	`bad option: -P:continuations:enable` is reported
    
    Simply because the continuations.jar can no longer be located.
    
    The fix is to somewhat restore the former implementation wrt how we handle the
    `-Xpluginsdir` compiler setting. Basically, the solution consists in not
    showing the default value of `-Xpluginsdir` to the user in the Preferences
    dialog, and pass this default to the different compiler instance we create
    unless the user specifices a different location (in which case, we do use the
    location provided by the user).
    
    There is one more catch due to the current way `ScalaProject.scalacArguments`
    is implemented (the method is used to pass the compiler arguments to the Sbt
    builder). In short, the returned arguments are only the ones forces by the user
    via the Preference dialog. Since the `-Xpluginsdir` default directory is
    **not** shown in the Preference dialog, the Sbt builder would fail to compiler
    projects with continuations enabled because it wouldn't know where to look for
    the continuations.jar. Hence, I had to add some ad-hoc code to handle this
    correctly in `ScalaProject.scalacArguments`.
    
    This whole fix is far from ideal, but I want to keep the changeset as small as
    possible to avoid regressions, since this commit should be included in the
    upcoming 3.0.0 release.
    
    By the way, all existing projects that were affected by the error should
    restore the defaults (Preferences > Scala > Compiler and hit the Restore
    Defaults button).
    
    Fixes #1001030, #1000700
    (cherry picked from commit aa2ecb9)
  4. Merge pull request #330 from dragos/isssue/tasks-disappear-1001401

    dragos committed Feb 25, 2013
    Use Scala specific task markers.(cherry picked from commit f248290)
Commits on Feb 23, 2013
  1. Uses a specific scala version for the version updater

    skyluc committed Feb 22, 2013
    (cherry picked from commit 24a421a)
Commits on Feb 22, 2013
  1. More robust against VM exceptions.

    dragos committed Feb 21, 2013
    * clearly report an actor shutting down because of an uncaught exception
      using the Eclipse Error log
    * gracefully handle the common VM exceptions.
    
    This is not exhaustive (a handful of FIXME notes are still in the codebase),
    but it is a step in the right direction and fixes a number of issues I've
    been seeing lately.
    
    Fixed #1001328, Refs #1001487.(cherry picked from commit a07bd6b)
  2. Possible deadlock fix.

    dragos committed Feb 14, 2013
    Two actors sending each-other synchronous messages
    may deadlock. Break the cycle by making one of them
    async.
    
    The cycle is:
    
    * a classPrepare event is fired, and listeners are
      notified
    * a breakpoint is deleted, and the breakpoint support
      actor de-registers from load events.
    
    I couldn't write a test to exercise this scenario,
    but I think it's worth discussing and see if we can
    ship it as is.
    
    I moved most sync message sends to `send with timeout`.
    Two sync message sends are still in the code base:
    one for debugging and one for initialising the
    breakpoint manager.
    
    Fixed #1001512(cherry picked from commit 4fc53e3)
  3. Implement 'Search test methods' in the Scala JUnit4 test runner.

    dragos committed Feb 12, 2013
    Hook into the JUnit test configuration tab and implement the
    Search Methods button functionality. We use aspects to intercept
    the right call, and route it to our `ITestKind` implementation.
    
    Fixed #1001474(cherry picked from commit c390cee)
Commits on Feb 21, 2013
  1. Merge pull request #322 from dragos/issue/revert-parse-tree

    huitseeker committed Feb 21, 2013
    Revert "Merge pull request #269 from mads379/parsetree-1001326"
  2. Merge pull request #325 from dotta/backport/3.0.x/project-settings-sh…

    dotta committed Feb 21, 2013
    …ould-not-trigger-rebuild-in-ui-thread-1001527
    
    [backport] Clean projects in a background job when project settings' change
  3. Merge pull request #324 from dotta/backport/3.0.x/dont-use-annotation…

    dotta committed Feb 21, 2013
    …-model-for-semantic-highlighting-1001156
    
    [backport] issue/dont-use-annotation-model-for-semantic-highlighting-1001156
  4. Clean projects in a background job when project settings' change

    dotta committed Feb 20, 2013
    Cleaning the projects in the UI Thread was causing UI freeze. The
    fix is really simple: clean the projects in a background job.
    
    Note: The implemented solution is inspired by the Eclipse
          ``CleanDialog`` component.
    
    Fixes #1001527
    (cherry picked from commit aec8edd)
  5. Deprecated ``SemanticHighlightingReconciliationPartecipant``s

    dotta committed Feb 1, 2013
    (cherry picked from commit 87e20d5)
  6. Java Semantic Highlighting can be disabled without using aspects

    dotta committed Feb 1, 2013
    (cherry picked from commit 05956d4)
  7. Disabled Java semantic highlighting in Scala source attachments

    dotta committed Feb 19, 2013
    Preventing the Java semantic highlighting engine to be installed
    on Scala sources attachments.
    
    By doing so, ``ScalaPresentationReconciler`` can now inherit from
    ``PresentationReconciler``.
    (cherry picked from commit 4ba2ba9)
  8. Faster and slicker Semantic Highlighting

    dotta committed Feb 1, 2013
    The former implementation of semantic highlighting was slow becuase of the
    following two reasons:
    
    First, the annotations created by the semantic highlighting component, where
    invalidated and recomputed every time the compilation unit was reconciled.
    
    Second, for the current implementation of the AnnotationModel, adding/removing
    an annotation is O(n^ 2). (The quadratic behavior is due to the implementation
    of ``CompilationUnitDocumentProvider#ReverseMap``, which is used by
    ``CompilationUnitDocumentProvider#CompilationUnitAnnotationModel#addAnnotation``.
    Basically, each time an annotation is added/removed, the ``ReverseMap`` class -
    which is backed by a linked list - is accessed to verify if the element exist.)
    
    The proposed solution is to apply semantic colorings directly on the editor's
    ``TextPresentation`` and hence no longer use the ``AnnotationModel``. This
    approach is both lightweight and orders of magnitude more efficient than the
    former.
    
    The way semantic highlighting works now is relatively simple. At a high level,
    there are only three key elements:
    
    * ``Presenter$SemanticHighlightingJob``: Given a compilation unit, it
      classifyies and collects all positions that need to be colored in the editor.
    
    * ``PositionsTracker``: Keeps track of currently highlighted positions in the
      editor.
    
    * ``TextPresentationEditorHighlighter$ApplyHighlightingTextPresentationChange``:
      Converts them into   ``StyleRange``s, and applies the styles to the editor's
      ``TextPresentation``.
    
    Of course the actual implementation contains a bit more than just the above
    mentioned classes, but most of it is needed to correctly handle platform's
    events such as the swapping of the document input (see
    ``Presenter$DocumentSwapListener`).
    
    There is however one important optimization that is worth mentioning, which is
    done to reduce to a minimum the editor's region whose styles need to be
    refreshed. Basically, whenever the user is typing in the editor, all positions
    that are **after** the cursor should be invalidated. If you are editing the
    beginning of a big file, almost the whole editor's text presentation would need
    to be refreshed. Furthermore, the mentioned approach would cause colors to
    flicker because all highlighted positions **after** the edit would be deleted
    (and hence the colors would be removed), and the new positions would get
    colored only **after** the semantic highlighting job completes. This is clearly
    not ideal, and it turns out it can be easily avoided by registering a
    ``IPositionUpdater`` on the editor's document. The concrete implementation of
    the listener (i.e., ``Presenter$PositionUpdater``) takes care of shifting -
    through side-effect - all currently highlighted positions that are **after**
    the edited region. The net effect is that colors never flicker.
    
    Bottom line, with the current implementation semantic highlighting is:
    
    * Considerably faster.
    * Never flickers.
    * Testable.
    
    If you wonder why the semantically highlighted positions are not stored in the
    document's model, the answer is that I simply could not see any benefit of
    doing so (why? because the document synchronizes access to the underlying
    position's map when adding/removing positions).  Furthermore, it is really easy
    to add the missing logic for storing the positions in the document's model, if
    in the future it turns out we need/want to do so.
    
    Fix #1001156
    
    Other facts about this commit:
    
    * Added the needed infrastructure for registering reconciling listeners (i.e.,
      ``IJavaReconcilingListener``) to the editor.
    
    * Created a ``UiThread`` trait needed for testing code that needs to be run
      within the UI Thread.
    
    Other tickets fixed by this commit:
    
    * Disabling semantic highlighting in the preferences now refreshes currently
      opened editors. Fixes #1001507
    
    * Changing semantic highlighting style's preferences now refreshes the
      currently opened editors. Fixes #1001508
    
    * Cache highlighting styles instead of creating the during
      ``TextPresentationEditorHighlighter.ApplyHighlightingTextPresentationChanges.applyTextPresentation``.
      This optimization has major consequence on the user's experience. I should also
      point out that ``ScalaSyntaxClass`` and ``SymbolTypes``  are quite messy and
      should be improved. However, I think this should be tackled in a different PR.
      Fixes #1001493, #1001489.
    (cherry picked from commit 9bfeb02)
  9. Uses sbinary '-pretending-SNAPSHOT' version

    skyluc committed Feb 18, 2013
    (cherry picked from commit b33b664)
Commits on Feb 20, 2013
  1. Revert "Merge pull request #269 from mads379/parsetree-1001326"

    dragos committed Feb 20, 2013
    The parse-tree changes have been merged in Scala [pull 1982](scala/scala#1982),
    so there is no need for it anymore. Moreover, the presentation compiler must *not* be interrupted
    while parsing on a foreign thread, and that can't be ensured in this commit (but is correctly ensured
    in the Scala changeset). Since this branch is used with 2.9.3, there is a potential for race conditions.
    
    This reverts commit 712e6bf, reversing
    changes made to 4f7b391.
  2. Make stepping as fast as in the JDT debugger.

    dragos committed Feb 15, 2013
    Two performance improvements in the way we handle stack frames:
    
    * make `variables` lazy. This way we don't retrieve variables values
      unless they are needed (most of the times, they are needed for only one
      frame in a full thread stack). Retrieving values requires a roundtrip
      to the debugged VM, hitting the network stack.
    
    * don't fire DebugEvents for creation of stack frames. This is the
      time consuming part: each frame (can be hundreds) fires one CREATE
      event that is put in a queue and a job-dispatch is scheduled to run for
      *each* frame in part. This floods the event queue and leads to
      lag times in the order of seconds (depending on the stack depth).
    
    I checked (in the debugger) that the JDT debugger does not fire CREATE
    events for stack frames, so I'm suggesting we do the same thing.(cherry picked from commit 96de8f0)
Commits on Feb 19, 2013
  1. Adds an extractor to check incompatible versions

    skyluc committed Feb 11, 2013
    The code is more self-contained.
  2. Adds a preference for the classpath validator

    skyluc committed Feb 8, 2013
    The preference allows to disable the search for jars not compatible with the current version of Scala.
    Limits the check to possible version of Scala >=2.8.0.
    
    Fixes #1001482
Commits on Feb 13, 2013
  1. Initialize symbols for primitive types on compiler startup.

    dragos committed Feb 11, 2013
    The nightly build uncovered a race condition in the indexer, that stepped on
    a case where `definitions.ShortClass` was not yet loaded, triggering the
    symbol loader.
    
    Needs back port. Should fix flaky presentation compiler tests.(cherry picked from commit bed8bfa)
Commits on Feb 12, 2013
  1. Merge pull request #314 from skyluc/backport/mark-occurrence-preferen…

    skyluc committed Feb 12, 2013
    …ce-1001466
    
    backport/mark occurrence preference 1001466
  2. Fixes problems in preference state sharing

    skyluc committed Feb 11, 2013
    Using only Boolean, and correctly starting the toggle handler listener.
  3. Added a Scala preference for Mark Occurrences

    skyluc committed Feb 7, 2013
    Added a toolbar button for quick access.
    Fixes #1001466
  4. Merge pull request #313 from sschaef/issue/backport-requires-keyword

    dragos committed Feb 12, 2013
    [backport] Issue/backport requires keyword
Commits on Feb 11, 2013
  1. Merge pull request #312 from dotta/backport/disable-debugger-remote-t…

    dragos committed Feb 11, 2013
    …ests-1001464
    
    [backport] Disabled flaky debugger ``RemoteConnectorTest`` tests class
  2. The keyword 'requires' is no longer shown as keyword

    kiritsuku committed Feb 9, 2013
    The parsing is done by Scalariform. Because it treats 'requires' still as a keyword,
    it needs to be translated to default content type.
    
    Fix #1000750
  3. Disabled flaky debugger ``RemoteConnectorTest`` tests class

    dotta committed Feb 11, 2013
    Re #1001464
    (cherry picked from commit b008729)
  4. Merge pull request #307 from dragos/backport/flaky-classpath-test

    dotta committed Feb 11, 2013
    [backport] Use a Job when reading classpath markers in test.
  5. Use a Job when reading classpath markers in test.

    dragos committed Feb 7, 2013
    The source of flaky tests was race condition in the classpath validator:
    * one thread removed the old markers and adds the new ones
    * the test thread waits until it finds a marker (which can happen before they are
    removed) and reads them again for validation (which can happen between 'delete'
    and 'add')
    
    The proper solution is to put the test reads inside a `Job` that is scheduled
    on the same resource (the project), leading to proper synchronization.(cherry picked from commit 7596e4c)
Commits on Feb 8, 2013
  1. Merge pull request #298 from gzsombor/handle-exceptions-with-closed-p…

    dragos committed Feb 8, 2013
    …rojects-for-3.0.x
    
    Add checks if the underlying project closed/not exists
Commits on Feb 7, 2013