Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Mar 13, 2013

  1. Mirco Dotta

    Merge remote-tracking branch 'upstream/release/scala-ide-3.0.x' into …

    …release/scala-ide-3.0.x-juno
    authored March 13, 2013
  2. Mirco Dotta

    Merge remote-tracking branch 'upstream/release/scala-ide-3.0.x' into …

    …release/scala-ide-3.0.x-juno
    authored March 13, 2013
  3. Mirco Dotta

    Merge pull request #352 from dotta/backport/3.0.x/issue/NPE-on-variab…

    …le-view-with-Eclipse-Juno-1001585
    
    [backport] Workaround for NPE in debugger variable view when using Eclipse Juno
    authored March 13, 2013
  4. Mirco Dotta

    Workaround for NPE in debugger variable view when using Eclipse Juno

    Unfortunately, the way we keep track of the currently selected thread in the
    Scala debugger isn't robust enough. Currently, we rely on a _selectionChanged_
    event to be sent when the Debug Perspective is opened. This worked fine with
    Eclipse Indigo, but it's no longer working with Eclipse Juno.
    
    The workaround is to look for the first suspended thread if
    ``ScalaDebugger.currentThread`` is null. This is far from being a proper fix,
    but it doesn't look like we have many alternatives. The Java debugger
    implementation seem to be using a DebugContextProvider/Manager/Event/Listener
    to know the thread associated to each variable. But using the debug context
    classes would require some import work, so it would be preferable to delay this
    for after the 3.0.0 final release.
    
    The workaround was suggested by @skyluc, and he believes the only issue this
    could lead to is visibility issues due to invoking a method call on the wrong
    thread (in case more than one is suspended), and hence the executing thread may
    see some stale values. Not an issue to be taken lightly.
    
    Fix #1001585
    
    backport to _release/3.0.x_
    (cherry picked from commit 2de89fe)
    authored March 12, 2013

Mar 12, 2013

  1. Mirco Dotta

    Merge pull request #350 from dotta/backport/3.0.x/issue/ISE-during-co…

    …de-completion-1001591
    
    [backport] Don't add arguments templates for parameterless method's completion
    authored March 12, 2013
  2. Mirco Dotta

    Don't add arguments templates for parameterless method's completion

    When asking for completion on a parameterless method we were trying to install
    arguments' templates. This operation in not allowed on parameterless methods,
    and it caused a ``java.lang.IllegalStateException: must specify at least one
    linked position`` during completion.
    
    ``explicitParamNames`` is a ``List[List[String]]`` (because of currying), hence
    a parameterless method is represented as ``List(List())``. The arguments'
    templates where added only if ``explicitParamNames`` is not empty, however a
    ``List(List())`` contains exactly one element (the empty list), hence it's
    never empty!  The fix is really simple, we just need to flatten the
    ``explicitParamNames`` before checking for emptiness.
    
    Fixes #1001591
    
    backport to _release/3.0.x_
    
    review by @dragos
    (cherry picked from commit d08e999)
    authored March 12, 2013

Mar 11, 2013

  1. Mirco Dotta

    Merge remote-tracking branch 'upstream/release/scala-ide-3.0.x' into …

    …release/scala-ide-3.0.x-juno
    authored March 11, 2013
  2. Mirco Dotta

    Merge pull request #348 from dotta/backport/issue/flaky-presentation-…

    …compiler-test-1001588
    
    [backport] Disabled ``implicitConversionFromPackageObjectShouldBeInScope`` PC test
    authored March 11, 2013
  3. Mirco Dotta

    Disabled ``implicitConversionFromPackageObjectShouldBeInScope`` PC test

    Disabling the test ``implicitConversionFromPackageObjectShouldBeInScope`` from
    PresentationCompilerTest because it often fails on our Jenkins machine (and
    that's just plain annoying), e.g.,
    https://jenkins.scala-ide.org:8496/jenkins/job/parameterized-scala-ide/168/console.
    This test has been flaky for at least a month now.
    
    Re #1001588
    (cherry picked from commit 02fbfe2)
    authored March 11, 2013
  4. Mirco Dotta

    Merge remote-tracking branch 'upstream/release/scala-ide-3.0.x' into …

    …release/scala-ide-3.0.x-juno
    authored March 11, 2013
  5. Mirco Dotta

    Merge pull request #346 from dotta/backport/3.0.x/issue/expanding-var…

    …iable-in-debugger-view-produces-NPE-1001586
    
    [backport] Expanding variable in debugger resulted in NPE
    authored March 11, 2013
  6. Mirco Dotta

    Expanding variable in debugger resulted in NPE

    The regression was introduced by SHA: be83fc8.
    
    The reason for the regression is that the name of the class
    ``ScalaLogicalStructureProvider`` was inadvertently changed to
    ``ScalaLogicalStructureProviders`` (note the final **s**). Since that class was
    linked to the *org.eclipse.debug.core.logicalStructureProviders* extension
    point, as soon as the debugger code needed to load that class an exception is
    reported.
    
    What we should do to avoid this sort of errors in the future is setting the PDE
    compiler flag for "References to non-existing classes" to *Error*. Furthermore,
    it would be good if this check could be enforced in our Tycho build (I've asked
    in the tycho-user ML,
    [here](http://dev.eclipse.org/mhonarc/lists/tycho-user/msg04110.html) is the
    link to the discussion).
    
    Fix #1001586
    
    Backport to _release/3.0.x_
    (cherry picked from commit ca3a67d)
    authored March 11, 2013

Mar 08, 2013

  1. Iulian Dragos

    Return `OK_STATUS` from the semantic highlighting job when the editor…

    … is dirty.
    
    Previously, we announced that the job finishes asynchronously (`ASYNC_FINISH`),
    but forgot to call `done` if the editor was dirty (and no UI asyncExec was
    performed at all). This lead in turn to the job manager thinking that the job
    is still running and not scheduling another run, ever, meaning the loss of
    semantic highlighting.
    
    Fixed #1001536.(cherry picked from commit 5e51152)
    authored March 08, 2013

Mar 06, 2013

  1. Mirco Dotta

    Merge remote-tracking branch 'upstream/release/scala-ide-3.0.x' into …

    …release/scala-ide-3.0.x-juno
    authored March 06, 2013
  2. Mirco Dotta

    Merge pull request #340 from dotta/backport/3.0.x/issue/handling-debu…

    …gger-runtime-exceptions-1001531
    
    [backport] Comply to the debugger interfaces by wrapping JDI runtime exceptions
    authored March 06, 2013
  3. Mirco Dotta

    Comply to the debugger interfaces by wrapping JDI runtime exceptions

    Several of the debugger interfaces we implement expect a ``DebugException`` to
    be thrown when the called method fails to execute. Failure can occur, for
    instance, when a debugger session is terminated by the user. Failing to wrap
    the JDI runtime exception in a ``DebugException`` can prevent the debugger to
    correctly work and the user is sometime forced to restart Eclipse.
    
    ``DebugException`` is a platform exception that is specially treated by
    Eclipse.
    
    If you wonder why do we have calls to ``safeStackFrameCalls`` in, for instance,
    ``ScalaStackFrame.getLineNumber``, the answer is: I don't think we need it. However,
    since we are in RCs cycle for the 3.0 release, I want to minimize the changes in
    this commit to avoid regressions.
    
    Fix #1001531
    (cherry picked from commit 60df6af)
    authored March 06, 2013
  4. Iulian Dragos

    Lazy retrieval of Java parameter names in completions.

    When a completion is selected we need to show the parameter names as placeholders.
    If the method comes from Java, we need to retrieve the Java element, a potentially
    long-running operation that can trigger the structure builder. Instead of retrieving
    all parameter names eagerly, for each completion proposal, we delay it to the
    moment a completion is selected and inserted in the editor.
    
    Fixed #1001560, #1001497.(cherry picked from commit ffcf62a)
    authored March 04, 2013

Feb 25, 2013

  1. Iulian Dragos

    Merge branch 'release/scala-ide-3.0.x' into release/scala-ide-3.0.x-juno

    authored February 25, 2013
  2. Mirco Dotta

    Merge pull request #333 from dotta/backport/3.0.0/cannot-enable-conti…

    …nuations-plugin-1001030
    
    Backport/3.0.0/cannot enable continuations plugin 1001030
    authored February 25, 2013
  3. Mirco Dotta

    Testing presentation compiler when project depends on continuations.jar

    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)
    authored February 25, 2013
  4. Mirco Dotta

    Do not force default location of -XpluginsDir in Scala Compiler Prefe…

    …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)
    authored February 24, 2013
  5. Iulian Dragos

    Merge pull request #330 from dragos/isssue/tasks-disappear-1001401

    Use Scala specific task markers.(cherry picked from commit f248290)
    authored February 25, 2013

Feb 23, 2013

  1. Luc Bourlier

    Merge branch 'release/scala-ide-3.0.x' into release/scala-ide-3.0.x-juno

    authored February 23, 2013
  2. Luc Bourlier

    Merge branch 'master' into platform/juno

    authored February 23, 2013
  3. Luc Bourlier

    Uses a specific scala version for the version updater

    (cherry picked from commit 24a421a)
    authored February 22, 2013

Feb 22, 2013

  1. Iulian Dragos

    More robust against VM exceptions.

    * 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)
    authored February 21, 2013
  2. Iulian Dragos

    Possible deadlock fix.

    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)
    authored February 14, 2013
  3. Iulian Dragos

    Implement 'Search test methods' in the Scala JUnit4 test runner.

    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)
    authored February 12, 2013

Feb 21, 2013

  1. François Garillot

    Merge pull request #322 from dragos/issue/revert-parse-tree

    Revert "Merge pull request #269 from mads379/parsetree-1001326"
    authored February 21, 2013
  2. Mirco Dotta

    Merge pull request #325 from dotta/backport/3.0.x/project-settings-sh…

    …ould-not-trigger-rebuild-in-ui-thread-1001527
    
    [backport] Clean projects in a background job when project settings' change
    authored February 21, 2013
  3. Mirco Dotta

    Merge pull request #324 from dotta/backport/3.0.x/dont-use-annotation…

    …-model-for-semantic-highlighting-1001156
    
    [backport] issue/dont-use-annotation-model-for-semantic-highlighting-1001156
    authored February 21, 2013
  4. Mirco Dotta

    Clean projects in a background job when project settings' change

    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)
    authored February 20, 2013
  5. Mirco Dotta

    Deprecated ``SemanticHighlightingReconciliationPartecipant``s

    (cherry picked from commit 87e20d5)
    authored February 01, 2013
  6. Mirco Dotta

    Java Semantic Highlighting can be disabled without using aspects

    (cherry picked from commit 05956d4)
    authored February 01, 2013
  7. Mirco Dotta

    Disabled Java semantic highlighting in Scala source attachments

    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)
    authored February 19, 2013
Something went wrong with that request. Please try again.