Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Jul 12, 2012
  1. @dragos

    Merge pull request #149 from dragos/issue/no-warning-when-library-is-…

    dragos authored
    Issue no warning when the Scala library is a project in the workspace
Commits on Jul 11, 2012
  1. @dotta

    Corrected implementation of ``ScalaMatchLocator$MethodLocator.paramet…

    dotta authored
    * Corrected implementation of ``ScalaMatchLocator$MethodLocator.parameterSizeMatches``
    * Using ``enclosingMethod`` instead of ``ScalaCompilationUnitgetElementAt(treePos)``
    * Created test for #1001135
    Fixed #1001135
  2. @dotta

    Implemented find references in constructor's super call

    dotta authored
    This commit is the direct consequence of the following observation:
    "expressions can only live inside methods".  And
    ``ScalaMatchLocator$MatchLocatorTraverser.enclosingMethod`` is the realization
    of this fact. Indeed, ``enclosingMethod`` retrieves the method's symbol
    enclosing the currently traversed expression.
    * Fixed implementation of ``ScalaMatchLocator $``.
  3. @dragos

    Added a test for working with the Scala library coming from a file, a…

    dragos authored
    …nd made the
    class path checker more lenient when the library comes from a project. In such a 
    case the version is assumed to be compatible (there is no file 
    inside the project, so we can't reliably guess the version).
  4. @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 10, 2012
  1. @dragos
Commits on Jul 6, 2012
  1. @dotta

    Merge pull request #143 from misto/issue/omit-or-prepend-scala-packag…

    dotta authored
    New option for Organize Imports to always omit/prepend the scala package
Commits on Jul 5, 2012
  1. @misto
  2. @dragos

    Merge pull request #141 from dragos/make-stdout-redirect-optional-100…

    dragos authored
    Make standard output/error redirection optional.
  3. @dragos

    Make standard output/error redirection optional.

    dragos authored
    By default, std out and error are redirected to the log file. This makes it
    difficult to do println debugging, and often each printed character ends up
    on a separate line in the log file. This PR makes it an option.
    Fixes #1001133
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 Jul 3, 2012
  1. @misto
  2. @dotta

    Fixed NPE occurring when creating a Scala Application using the wizard

    dotta authored
    This could occur if no Scala project was selected, e.g., by clicking on a
    closed project (or outside of the Package Explorer) and File > New > Scala
    Application, the reported NPE would have occurred.
    Fix #1000797, #1001115
Commits on Jul 1, 2012
  1. @misto

    Use textual instead of Java search to find files to index.

    misto authored
    Instead of using a Java search for files that need to be included
    in the refactoring index, we use a simple textual search. The problem
    with the Java search was that it didn't find all occurrences of a term,
    e.g. when a file contained only an import of a type, it wasn't found
    by the Java search and thus not indexed and consequently not part of
    the rename refactoring.
    Fixes #1001117
Commits on Jun 29, 2012
  1. @misto

    Merge pull request #129 from misto/issue/organize-imports-user-format…

    misto authored
    Pass the user's formatting options to the refactoring library codegen.
Commits on Jun 28, 2012
  1. @dotta

    Warn the user if JDT Weaving is OFF

    dotta authored
    At startup, check that JDT Weaving is enabled. If it's not, then
    warn the user through a dialog box and programmatically
    enable JDT Weaving (and restart the workbench) upon confirmation.
    Note that there is no way for the user to silent the dialog. Each time the
    Scala IDE plugin is activated the check will be performed, and if JDT
    Weaving is OFF the above mentioned message will be displayed. If the
    user doesn't want to see the dialog, it will have three options:
    * Enable JDT Weaving
    * Disable the Scala IDE core bundle (using the OSGi console)
    * Uninstall the Scala IDE plugin
    Fix #1001113
  2. @michih57
Commits on Jun 27, 2012
  1. @michih57
  2. @michih57

    improved source generators

    michih57 authored
    when generating hashCode and equals (and canEqual) implemenations and the class has already implementations for some of these methods, the user now can choose either to keep or replace his implementations.
  3. @michih57

    Moved source generators to Source menu, properly handle refactoring p…

    michih57 authored
    …reparation errors.
    Generate hashCode and equals and Introduce ProductN trait now show up in the Source context menu. This is done programmatically in ScalaSourceFileEditor#editorContextMenuAboutToShow, so they are removed from plugin.xml.
    When a refactoring fails in the preparation step this is now properly handled, the error message is presented in a dialog.
  4. @michih57
  5. @michih57

    Added indexHints method to IndexedRefactoring to provide subclasses a…

    michih57 authored
    … hook to speed up index building.
  6. @michih57

    Extending the refactoring support by integrating new refactorings fro…

    michih57 authored
    …m the refactoring library.
    The new integrated refactorings are:
    - Method signature refactorings:
      - Change parameter order (within parameter lists)
      - Split parameter lists
      - Merge parameter lists
    - Extract trait
      Extracts class members (val/var/def) to a new trait
    - Move constructor to companion object
      Redirects calls constructor calls to a newly generated apply-method of the companion object.
      If necessary, the companion object is generated as well.
    - Source generators:
      - Generate hashCode and equals
      - Introduce ProductN trait
        Generates methods to implement ProductN for selected class parameters.
        This includes generation of hashCode and equals.
  7. @dotta
  8. @dotta

    Don't allow ``ScalaPlugin`` this instance to escape during construction

    dotta authored
    * This is a classic way to create potential data races, so better to avoid it altogether.
  9. @dotta

    Merge pull request #130 from dotta/issue/ghost-error-1000976

    dotta authored
    Created tests for ticket #1000976 (ghost errors in the editor)
  10. @dotta

    Refactoring: Moved logic for opening a source in ``ScalaSourceFile``

    dotta authored
    * Added three new methods ``forceReload``, ``reload`` and ``discard`` in
    ``ScalaSourceFile``, and moved the logic from ``ScalaPlugin`` to
    ``ScalaSourceFile ``. This was done also for testing purposes (next
    commit), as I needed a way to exercise the opening of a source file
    (without having to duplicate the logic).
    * As a side remark, I wonder if there isn't an already existing method in
      ``ScalaSourceFile`` that we should override to run the logic that is in
    ``reload/discard``. I though ``open(IProgressMonitor)`` could be the right one,
    but that method doesn't seem to be called when opening a source file in the
  11. @dragos

    Merge pull request #132 from dragos/forward-pc-verbose-messages

    dragos authored
    Forward verbose messages from the presentation compiler.
Commits on Jun 26, 2012
  1. @dotta

    Merge pull request #125 from dotta/issue/initial-support-find-referen…

    dotta authored
    initial support find references 1000868
  2. @dragos
  3. @dotta
  4. @dotta
  5. @dotta

    Correctly handle find references on class type

    dotta authored
    In ``ScalaMatchLocator.reportObjectReference`` only object references are reported, hence we are not interested in constructors. That's why we look at the element's parent if a ConstructorElement is returned for the passed position. The reason why in ``ssf.getElementAt`` can be a constructor has to be looked in the implementation of the ``ScalaStructureBuilder`` and ``ScalaCompilationUnit.getSourceElementAt``.
    Fix #1001084
  6. @dotta

    Correctly handle find references on field declarations

    dotta authored
    When Find References was performed on a val/var declaration, a popup dialog
    used to be shown saying:
    > The operation is unavailable on the current selection. Please select a valid
    > Java element name.
    The issue is in the compiler symbol found for the val/var declaration.
    It turns out that the symbol's name can contain a trailing space, which
    caused the equality test between the editor's current selection and the
    symbol's name to always fail.
    A test was also created to prove the issue is now corrected.
    Re #1000773
Something went wrong with that request. Please try again.