Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Feb 25, 2013

  1. 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

Feb 13, 2013

  1. Iulian Dragos

    Initialize symbols for primitive types on compiler startup.

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

Feb 07, 2013

  1. Zsombor

    Add checks if the underlying project closed/not exists

    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
    authored January 28, 2013

Feb 05, 2013

  1. Iulian Dragos

    Rebuild Scala projects after a global compiler settings change.

    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.
    authored January 31, 2013

Feb 04, 2013

  1. Iulian Dragos

    Remove `Xmigration28` setting.

    Fixed build for 2.10.1-SNAPSHOT.
    authored February 04, 2013

Jan 04, 2013

  1. Rafał Krzewski

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

    …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.
    authored December 14, 2012

Dec 04, 2012

  1. Iulian Dragos

    Correctly update project settings when the preferences change.

    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
    authored December 04, 2012

Sep 02, 2012

  1. Iulian Dragos

    Don't overlog windows that are open/closed.

    authored September 02, 2012

Aug 07, 2012

  1. Eugene Vigdorchik

    Use stock sbt 0.13 from eclipse

    * 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
    authored July 25, 2012 dotta committed August 07, 2012

Jul 27, 2012

  1. Iulian Dragos

    More abstract dealings with Scala compilation units.

    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.
    authored July 27, 2012

Jul 21, 2012

  1. Iulian Dragos

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

    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.
    authored July 21, 2012

Jul 18, 2012

  1. Mirco Dotta

    Fixed exception occurring when deleting or closing a Scala project

    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).
    
    Improvement
    ...........
    
    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
    optimization.
    
    Tests
    .....
    
    Unfortunately, the changes cannot be tested in a UI-less environment, hence no
    tests.
    
    Fixed #1001058
    
    Integrated comments from pull #154
    authored July 16, 2012
  2. Mirco Dotta

    Some code cleanup

    * Removed unused methods.
    * Renamed ``Scalaproject.initialize`` into ``ScalaProject.initializeSettings``
    * Improved encapsulation of members.
    authored July 16, 2012

Jul 13, 2012

  1. Iulian Dragos

    Fixed warnings.

    - 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
    authored July 13, 2012

Jul 11, 2012

  1. Iulian Dragos

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

    …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.
    authored July 11, 2012

Jul 04, 2012

  1. Mirco Dotta

    Refactoring in ``ScalaProject``

    * 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.
    authored July 01, 2012
  2. Mirco Dotta

    Truncate too long build error messages displayed in resources' marker

    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
    ``ScalaProject.buildErrors``.
    
    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
    authored June 29, 2012

Jun 26, 2012

  1. Mirco Dotta

    Minor refactoring in ``testsetup`` classes

    * 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
    authored June 17, 2012
  2. Mirco Dotta

    Better implementation of ``ScalaProject.sourceFolders``

    No need to traverse the collection twice.
    authored May 31, 2012

Jun 18, 2012

  1. Mirco Dotta

    Better encapsulation of ``ScalaProject`` members

    * Reduced visibility of methods
    * Removed unused member ``scalaProject``
    authored June 15, 2012
  2. Iulian Dragos

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

    …e-lib-1000729
    
    Correct handling of source Scala libraries on the class path.
    authored June 18, 2012

Jun 14, 2012

  1. Luc Bourlier

    Clean file handle on refreshing changed files

    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
    authored June 14, 2012

Jun 12, 2012

  1. Iulian Dragos

    Correct handling of source Scala libraries on the class path.

    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.
    authored June 05, 2012

May 24, 2012

  1. Iulian Dragos

    Extracted classpath management into its own trait.

    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).
    authored May 24, 2012

May 17, 2012

  1. Mirco Dotta

    Merge pull request #108 from JamesEarlDouglas/master

    Fix typo: "paramters"
    authored May 17, 2012

May 16, 2012

  1. Iulian Dragos

    Fixed deprecation warnings for things that are deprecated since 2.9.0…

    … and may be removed in 2.10.
    authored May 16, 2012

May 11, 2012

  1. James Earl Douglas

    fix typo: s/paramters/parameters/g

May 10, 2012

  1. Iulian Dragos

    Use the configured JDK when instantiating the presentation compiler.

    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
    builder.
    authored May 10, 2012

Apr 26, 2012

  1. Iulian Dragos

    Don't show the dialog if the presentation compiler fails to initializ…

    …e in headless mode.
    authored April 26, 2012

Mar 13, 2012

  1. Matt Russell

    Add initial support for semantic highlighting

    authored December 21, 2011 dotta committed March 13, 2012

Feb 29, 2012

  1. Iulian Dragos

    Incorporated reviewer's comments.

    authored February 29, 2012
  2. Iulian Dragos

    Fixed transitive and direct dependencies for project builders.

    authored February 11, 2012

Feb 17, 2012

  1. Mirco Dotta

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

    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
    directory.
    
    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: https://issues.scala-lang.org/browse/SI-5491.
    
    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.
    authored February 17, 2012

Feb 16, 2012

  1. Mirco Dotta

    Logging more info about settings initialization in ScalaPlugin. No re…

    …view.
    authored February 16, 2012

Feb 09, 2012

  1. Iulian Dragos

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

    …atform independent. Fixes #1000901.
    authored February 09, 2012
Something went wrong with that request. Please try again.