Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Feb 25, 2013
  1. @dotta

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

    dotta authored
    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)
Commits on Feb 13, 2013
  1. @dragos

    Initialize symbols for primitive types on compiler startup.

    dragos authored
    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 7, 2013
  1. @gzsombor

    Add checks if the underlying project closed/not exists

    gzsombor authored
    There are scenarios, where project depends on other, closed projects -
    this happens with IvyDE, which adds even closed projects to the dependency
    list (of course, in that case, the generated jars added as well), but
    these closed projects cause build failures for ScalaIDE, because it
    doesn't expects that the underlying IJavaProject could throw exceptions.
    So the general fix is to add checks before calling the critical methods,
    and a catch block with logging.
     This fixes #1001465
Commits on Feb 5, 2013
  1. @dragos

    Rebuild Scala projects after a global compiler settings change.

    dragos authored
    If the user changes compiler settings on the Scala Preferences page, all Scala
    projects that 'inherit' these settings should be rebuild. The existing logic
    was dealing only with the case where *project-specific* settings were changed.
    Fixed #1001460.
Commits on Feb 4, 2013
  1. @dragos

    Remove `Xmigration28` setting.

    dragos authored
    Fixed build for 2.10.1-SNAPSHOT.
Commits on Jan 4, 2013
  1. @rkrzewski

    Fix #1001394 Ignore source classpath entries that don't exist physica…

    rkrzewski authored
    …lly in the workspace.
    m2e routinely adds optional CPEs for src/main/java, src/test/java even when
    the directories are missing. SBT builder is not aware that they are optional
    and aborts compilation.
Commits on Dec 4, 2012
  1. @dragos

    Correctly update project settings when the preferences change.

    dragos authored
    The `PropertyStore` class is a snapshot, and during the move to sbt 0.13 the storage
    became a lazy-val, meaning we started to lose project settings.
    Fixed #1001241
    Fixed #1001267
Commits on Sep 2, 2012
  1. @dragos
Commits on Aug 7, 2012
  1. @vigdorchik @dotta

    Use stock sbt 0.13 from eclipse

    vigdorchik authored dotta committed
    * Move sbt to 2.9.2 for 2.9.x series.
    * Use short sbt.compiled.version for 2.10.x
    * Use full version of sbinary.
    * Fixed continuation plugin test: Continuations plugin is _not_ enabled by default in 2.10
Commits on Jul 27, 2012
  1. @dragos

    More abstract dealings with Scala compilation units.

    dragos authored
    We need a way to treat uniformly different kinds of Scala-based sources. Until now
    we routed everything through `ScalaCompilationUnit`, that extends the JDT `CompilationUnit`
    class. This tight connection is counter-productive, and in most cases, unnecessary.
    This commit is a step towards extracting a set of interfaces for other Scala-based
    sources to benefit of reconciliation ('errors-as-you-type'), hyperlinking and completion
    engine that already exists.
    * extracted `InteractiveCompilationUnit` as a super type of `ScalaCompilationUnit`
    * switched from `ScalaCompilationUnit` to `InteractiveCompilationUnit` wherever possible, to allow
    hyperlinking to work in the scala-worksheet project
    * added a utility method to retrieve the compilation unit associated with an open editor that
    uses the platform adapter protocol to allow other plugins to participate.
Commits on Jul 21, 2012
  1. @dragos

    Only react to part-closed events related to the current project.

    dragos authored
    This regression manifested by having a Scala compiler started on all Java projects when
    a file was closed. Annoyingly, that lead to the FailedCompilerInitialization window asking
    about adding the Scala library.
Commits on Jul 18, 2012
  1. @dotta

    Fixed exception occurring when deleting or closing a Scala project

    dotta authored
    Issue Description
    The issue was occurring only when a source was open in the editor and the
    corresponding project was deleted/closed. Apparently, when deleting/closing a
    project, any of its opened sources can still be reconciled (this only happens
    if you have the Java breadcrumb enabled in the editor). The problem with
    running the reconciler on a virtual source (i.e., the source does no longer
    exist in the filesystem) is that the reconciler participants (e.g., semantic
    and implicit highlight presenters) expect the source file to phisically exist.
    When that's not the case, a ``java.lang.IllegalArgumentException`` was thrown
    to the user's face.
    Implemented Solution
    The current fix is to check in ``SemanticHighlightReconcilationParticipant``
    that the compilation unit is linked to an existing (and currently opened)
    project (i.e., the project actually exist in the filesystem).
    Mind that this is actually *not* a proper fix, but a workaround. The problem is
    that the ``SemanticHighlightingReconciliation`` mantains a map of
    ``ScalaCompilationUnit`` to ``SemanticDecoratorManager``, and the map is not
    properly cleaned when a project is deleted/closed.  This is a memory leak and
    the only way I see to properly fix this is to completely re-work the way
    semantic highlighting is executed (Re #1001156).
    Furthermore, when a Scala project is about to be deleted, the Scala project is
    now disposed (i.e., the presentation compiler is shut down). This was not
    needed to fix the issue described in this commit, but it seemed a valid
    Unfortunately, the changes cannot be tested in a UI-less environment, hence no
    Fixed #1001058
    Integrated comments from pull #154
  2. @dotta

    Some code cleanup

    dotta authored
    * Removed unused methods.
    * Renamed ``Scalaproject.initialize`` into ``ScalaProject.initializeSettings``
    * Improved encapsulation of members.
Commits on Jul 13, 2012
  1. @dragos

    Fixed warnings.

    dragos authored
    - catching `Throwable` (in 2.10 only). I tried to make sense of each case, and where safe replace `Throwable` by a smaller type. Not always possible
    - unchecked warnings (in one case it was completely wrong) in pattern matches
    - missing cases in a pattern match
Commits on Jul 11, 2012
  1. @dragos

    Don't report nonexistent projects in `directDependencies`. The JDT ha…

    dragos authored
    …s a very annoying habit of
    caching dependent projects, and there's no way to clear that cache. I've seen the build fail because it
    thought it depends on a nonexistent project. Neither closing, refreshing or restarting Eclipse helped,
    so we filter it explicitly here.
Commits on Jul 4, 2012
  1. @dotta

    Refactoring in ``ScalaProject``

    dotta authored
    * Moved ``toString`` declaration.
    * Both ``javaProject`` and ``transitiveDependencies`` members declared in a single line.
    * Shortened references to ``ScalaPlugin.plugin`` to ``plugin`` alone.
    * Explicit type for API members.
    * Renamed a few methods to better express intent.
    * Improved members encapsulation.
    * Organized imports.
  2. @dotta

    Truncate too long build error messages displayed in resources' marker

    dotta authored
    Markers are a general mechanism for associating notes and meta-data with
    resources.  The Eclipse environments dictates that the text message passed to a
    marker should not be bigger than 21000 chars, or an assertion failure saying
    > Marker property value is too long
    is thrown on the user's face.
    The actual logic for resizing the build error problem passed to a marker
    already existed in two places. While the message passed to the created marker
    was correctly truncated in ``FileUtils.buildError``, it was not in
    As part of this commit, I've centralized the creation of resource markers in
    ``MarkerFactory``, and build problem markers are now created using
    ``BuildProblemMarker`` (it's a subclass of ``MarkerFactory```).
    More cleaning up could be done so that all markers are created only through
    sublcasses of `MarkerFactory``. Though, such a big refactoring seem too risky
    at the moment, as this commit will be merged in ``release/2.0.x`` branch.
    Fix #1001107
Commits on Jun 26, 2012
  1. @dotta

    Minor refactoring in ``testsetup`` classes

    dotta authored
    * Removed ``ScalaUnit`` type alias and replaced usage of ``ScalaUnit`` with ``ScalaSourceFile``.
    * Added explicit method's return type.
    * Changed signature of ``SDTTestUtils.addFileToProject``: the passed ``content`` is now an ```Array[Byte]`` instead of a plain ``String``.
    Note: This commit should be probably backported in 2.0.x branch
  2. @dotta

    Better implementation of ``ScalaProject.sourceFolders``

    dotta authored
    No need to traverse the collection twice.
Commits on Jun 18, 2012
  1. @dotta

    Better encapsulation of ``ScalaProject`` members

    dotta authored
    * Reduced visibility of methods
    * Removed unused member ``scalaProject``
  2. @dragos

    Merge pull request #117 from dragos/issue/separate-runtime-compiletim…

    dragos authored
    Correct handling of source Scala libraries on the class path.
Commits on Jun 14, 2012
  1. @skyluc

    Clean file handle on refreshing changed files

    skyluc authored
    The custom code I wrote to read an IFile was not releasing the file
    handle correctly.
    It was eventually closed when the object was GCed.
    Replaced the code with some internal jdt util method.
    Removed the incorrect method
    Fix #1000909
Commits on Jun 12, 2012
  1. @dragos

    Correct handling of source Scala libraries on the class path.

    dragos authored
    If a dependent project provides a Scala library as source, use the output directory
    as the bootclasspath for the current project.
    Don't filter out the Scala library from the class path. This allows compiling the Scala library itself.
Commits on May 24, 2012
  1. @dragos

    Extracted classpath management into its own trait.

    dragos authored
    Extended the logic for finding the Scala library in source folders, and not to rely on the 
    JDT (and implicitly the presentation compiler being present).
Commits on May 17, 2012
  1. @dotta

    Merge pull request #108 from JamesEarlDouglas/master

    dotta authored
    Fix typo: "paramters"
Commits on May 16, 2012
  1. @dragos

    Fixed deprecation warnings for things that are deprecated since 2.9.0…

    dragos authored
    … and may be removed in 2.10.
Commits on May 11, 2012
  1. @earldouglas
Commits on May 10, 2012
  1. @dragos

    Use the configured JDK when instantiating the presentation compiler.

    dragos authored
    The Scala compiler adds the currently running JDK to the class path, taking precedence over the JDK 
    configured in the build path. This commit fixed #1000820, and generalizes the scheme used by the Sbt
Commits on Apr 26, 2012
  1. @dragos
Commits on Mar 13, 2012
  1. @mdr @dotta

    Add initial support for semantic highlighting

    mdr authored dotta committed
Commits on Feb 29, 2012
  1. @dragos
  2. @dragos
Commits on Feb 17, 2012
  1. @dotta

    Override default when an explicit value is provided for `-XpluginsDir`.

    dotta authored
    In the IDE, for convenience we use to se the value of `-XpluginDir` to the
    default location in the distribution that contains the continuations.jar
    plugin.  This is convenient because users need only to pass
    `-P:continuations:enable` to use the continuations plugin.
    If in the IDE an explicit value is provided for `-XpluginsDir`, then we simply
    concatenate the user's provided plugins' directory to the default one.  This
    generally works fine and allows users to keep using the continuations plugin
    without having to copy the continuations.jar in the provided user's plugin
    However, by passing the additional parameter -Xplugin
    ${path-to-continuations-plugin}, the compiler is unable to load the
    continuations.jar. The reason is that there is ambiguity. `-XpluginsDir`
    instructs the compiler to load all plugins available in the passed
    directory(ies) and, as we said in the first paragraph, that means that the
    continuations' plugin gets always loaded. Now, when also `-Xplugin
    ${path-to-continuations-plugin}` the Scala compiler seems to get lost because
    it sees the continuations.jar twice, and it looks like it decided to simply not
    load it. Hence, the compiler will complain that the continuations plugin isn't
    enabled. That looks like a bug, and a ticket in the Scala compiler JIRA has
    been created for this:
    But in consideration of what has been said, I believe that we should not try to
    always set `-XpluginsDir` to point to the default location in the distribution.
    If the user decides that it should point to some other place, then provided
    location should be used. That actually matches the Scala compiler's behavior.
    Fix #1000908.
Commits on Feb 16, 2012
  1. @dotta
Commits on Feb 9, 2012
  1. @dragos

    Use File.pathSeparator when building the pluginsDir setting, to be pl…

    dragos authored
    …atform independent. Fixes #1000901.
Something went wrong with that request. Please try again.