Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Feb 14, 2014
  1. @dragos

    Package structure reorganisation.

    dragos authored
    This commit keeps all filenames unchanged, but builds a cleaner
    package structure of the IDE.
    
    There are only 5 top-level packages now:
    - core
    - ui
    - logger
    - util
    - refactoring
    
    Code is split in internal and API packages. Note that this commit
    only touches directories, and the API work (clean up, documentation,
    interfaces) will follow.
    
    The guideline was to keep related code together. The only exception is
     ui code, that is moved to its top-level package. Additional dimensions
     (for example, following Eclipse concepts like launchers or preferences
     would make it too hard to decide what goes where).
    
    Two unused files were removed:
    
    - JVMUtils
    - util/Colors.scala
    
    This organisation makes it easier to see duplicated functionality (like
    several RegionOps implicit classes). However, to keep things simple, that work is delayed to follow up PRs, so code changes can be independently 
    and easily reviewed.
Commits on Sep 30, 2013
  1. @sschaef

    Clean up code base

    sschaef authored
    The new warnings of 2.11 made a great deal.
    
    - Removal of unused code
    - Change var to val when possible
    - Remove unused imports
Commits on Jun 30, 2013
  1. @sschaef
  2. @sschaef
  3. @sschaef
  4. @sschaef
  5. @sschaef
Commits on Jun 24, 2013
  1. @huitseeker

    In the immortal words of @paulp:

    huitseeker authored
     "Can we please, please not do this:
    
      import PatternMatchingStats._
      import global.{phase, currentRun, Symbol,
        Apply, Bind, CaseDef, ClassInfoType, Ident, Literal, Match,
        Alternative, Constant, EmptyTree, Select, Star, This, Throw, Typed, UnApply, (...)"
    
    Let's simplify merges, by making our imports mono-line !
    
    Thanksfully, in the IDE, we don't do (many) *mutli-line* braced Imports, so it
    was enough to filter them with the following one-liner:
    
    for i in `find ./ -type f -name "*.scala"`; do perl -nle 'if (m/^(\s*)import\s([^\n]+?){([^}]*?)}$/smg){my ($s,$x,@y)=($1,$2,split /,\s*(?!_|\s)/,$3); foreach $dep (@y){$dep =~ s/^\s+|\s+$//g; $dep=($dep =~ m/=>/)?"{ $dep }":$dep;print "${s}import $x$dep";}} else {print $_;}' $i > $i.nu; mv $i.nu $i; done
    
    Note the negative lookahead to avoind busting final wildcards in
    braced imports (see the Spec version 2.9, section 4.7), .
    
    If you want to do this on a repo that contains multi-line braced
    imports, look into unsetting the special variable '$/' of perl, and
    relax the condition on the presence of new lines in the second capture
    group of the regex above. I strongly advise against doing this
    automatically on such a repo, though.
    
    Fixes of multiline braced imports (manual).
    
    Let this be the end of this lazy, messy, mergepain-inducing practice.
    
    Fixing test relying on braced import.
Commits on Jun 3, 2013
  1. @dotta

    Merge pull request #425 from dotta/issue/structure-builder-throws-exc…

    dotta authored
    …eption-1001707
    
    Issue/structure builder throws exception 1001707
  2. @dotta

    Removed all calls to `List.head` in `StructureBuilder`

    dotta authored
    Calling `List.head` is in general a bad idea, and that alone is good enough
    motivation for not doing it. Furthermore, as ticket #1001707 demonstrates, the
    call to `head` can throw an exception in the `ScalaStructureBuilder`.
    
    The exception is likely thrown for Scala sources that contain type errors,
    because not all expected information may be available in some of the inspected
    symbols. For instance, a class is expected to always have at least one
    superclass, however if there are type errors it is possible for a class symbol
    to have no superclasses, and hence accessing the `head` of an empty `List`
    will result in a `NoSuchElementException` being thrown.
    
    This fix comes with no tests because the ticket didn't provide a reproducible
    test case.
    
    Fix #1001707
Commits on May 31, 2013
  1. @dotta

    Small refactoring in `ScalaStructureBuilder`

    dotta authored
    Method `unresolvedType` does not need any argument.
  2. @dragos

    Synchronize access to `Names` in the presentation compiler.

    dragos authored
    This may lead to subtle errors, like the mysterious
    assertion error in pickler.
    
    Refs #1001607, #1001606
  3. @sschaef

    Update of codebase to conform the rules of Scalastyle

    sschaef authored
    This commit contains:
    
    - Correction of tests that rely on trailing white spaces.
    - A fix of a package name in a test unit.
    - Removal of trailing white spaces and tabs in the whole project.
      The changes are all done automatically with the following
      commands:
    
      (Conversion of tabs to white spaces)
      find . -iname "*.scala" -print0 | xargs -0 sed -i 's/\t/  /g'
    
      (Removal of trailing white spaces)
      find . -iname "*.scala" -print0 | xargs -0 sed -i 's/ *$//'
    
    - To is some content added to an empty Scala file to solve a
      Scalastyle warning.
Commits on Apr 23, 2013
  1. @dragos @huitseeker

    JVMUtil went away, workaround that.

    dragos authored huitseeker committed
Commits on Apr 19, 2013
  1. @dotta

    Removed the extra source folder in sdt.core that allowed master to co…

    dotta authored
    …mpile with
    
    both Scala 2.9 and Scala 2.10
    
    Fix #1001674
Commits on Apr 15, 2013
  1. @huitseeker

    Dropped 2.8 compatibility.

    huitseeker authored
    - remove longstanding workaround for 2.8
    
    - removed 2.8 compatibility method
    
    - removed irrelevant 2.8 compatibility comment
    
    - dropped two compatibility members for 2.8 in Annotations trait
Commits on Sep 17, 2012
  1. @dragos
Commits on Jul 31, 2012
  1. @sschaef
Commits on Jul 25, 2012
  1. @dotta

    Fix #1001173, #1001174 - Correctly expose abstract val/var to JDT

    dotta authored
    Abstract val/var were being ignored in the ``ScalaStructureBuilder`` and
    therefore no ``IJavaElement`` was being created. Indeed, abstract val/var are
    represented in scalac as ``DefTree``, and the attached symbol has the ACCESSOR
    flag set (that because the symbol that is attached to abstract val/var is
    always the getter symbol, i.e., its accessor).
    
    The fix consisted in simply not pruning ``DefTree`` that have the ACCESSOR flag
    set (this fixed #1001173).
    
    A nice side effect of the fix is that missing implementation of abstract val/var
    are now reported in Java sources (which fixes #1001174).
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 Jun 26, 2012
  1. @dotta
Commits on May 15, 2012
  1. @dotta

    Correctly expose to JDT Scala sources' throws annotations

    dotta authored
    Scala @throws annotation were not exposed to JDT up until now, which was
    causing wrong errors to be reported by the Scala presentation compiler.
    
    Fix #1001005, #1000707 and #1000800
Commits on Apr 26, 2012
  1. @dragos

    Fix for 2.10 compatibility: `ClassTag` is now a class, coming from Pr…

    dragos authored
    …edef. In the quest for source compatibility we assume there are no other tags and fallback to the class tag.
Commits on Jan 16, 2012
  1. @dragos
Commits on Nov 16, 2011
  1. @dotta

    Entities nested in a Type Member definition are *not* traversed, beca…

    dotta authored
    …use the Eclipse Java Outline that we currently
    
    use does not handle members defined in a {{{ org.eclipse.jdt.internal.core.SourceField }}} (which is the data structure
    we use to expose type members definition to JDT).
    
    For instance, the following is not correctly handled by the Outline when you click on the nested member `a`:
    
        {{{type AkkaConfig = a.type forSome { val a: AnyRef }.
    
    Hence, for safety, currently it is better to skip all children altogether. Fix #1000748.
Commits on Nov 6, 2011
  1. @dotta

    To be visible from Java sources, classes nested in a module have to b…

    dotta authored
    …e exposed as children
    
    of the module's companion class (this matches the Scala compiler's behavior). To this end,
    when traversing a ClassDef tree node, we were checking its symbol's owner to know if the
    declaration was nested in a module. This manipulation was from time to time preventing the
    structure builder to correctly traverse the file (and produced an exception:
    'java.lang.Error: no-symbol does not have owner').
    
    The issue is that symbols in the structure builder have to be handled with care, as we deal
    with trees that are not fully typechecked, and consequently most symbols are not set.
    
    Therefore, I reworked the way we check if a ClassDef is nested in a module, and no symbol is
    used this time to carry out the check.
    
    Furthermore, I noticed a slight regression, i.e., ClassDefs nested in a module where no longer
    shown as children of the module in the Eclipse Outline (this because they were traversed as
    children of the module's companion class, which may not exist in the editor, and hence it would
    not be shown in the Outline).
    The underneath problem is that the Outline is currently too coupled to the structure builder,
    and therefore no real solution exist to correctly build the Outline view (without a major rewriting,
    which it can't happen now).
    The current solution is to show ClassDefs nested in a module twice if both the module and the
    companion class exist. This is not ideal, but in this way ClassDefs nested in a module will
    be reported in the Outline view.
Commits on Oct 27, 2011
  1. @dotta

    Updated code accordingly to review in pull request #18. Added quite a…

    dotta authored
    … few more test for checking that Java code can correctly reference trait's types.
  2. @dotta

    Updated ScalaStructureBuilder, as it is responsible of correctly expo…

    dotta authored
    …sing module's inner classes to JDT. The issue was that module's inner classes were exposed as member of the $ module class, which is wrong, since the scala compiler expose them as inner classes of the module's companion class.
    
    I moved the code that was responsible of traversing the Scala AST Tree into a new class 'TreeTraverser', that takes a new field 'module2innerClassDefs' used to keep track of inner classes that are defined in a module. This solution has the advantage of avoiding possible memory leaks that could result from not correctly cleaning the 'module2innerClassDefs' map.
    
    Fixed ticket Re #1000678.
Commits on Oct 20, 2011
  1. @dragos

    Make sure the structure builder reports the same number of parameter …

    dragos authored
    …names as
    
    parameter types.
    
    This prevents crashes later (particular case was that the
    generic type signature contain the 'outer' pointer, while the parameter names
    ignored it). Fixed #1000686.
Commits on Oct 7, 2011
  1. @dotta

    Unified logging under a single component Re #1000649. As part of this…

    dotta authored
    … commit I have replaced all calls to println with logger.debug or logger.info. This is much cleaner, IMO.
    
    There were mainly two reasons for refacting and unify the logger:
    
    1) Testing. It was previously impossible to mock the logger, which is a problem because I couldn't create a functional test for Re #1000531.
    
    2) Eventually we want to use Log4J (or similar) as a back-end logger (which ideally could be easily configured by customers). This is something we yet didn't explore and it will likely be tackled after releasing 2.0.
Commits on Oct 1, 2011
  1. @dotta

    Sometime type parameters' positions seem to be undefined and this mak…

    dotta authored
    …es the ScalaStructureBuilder failing (the exception is swallowed and an entry appear in the Error Log). To prevent this,check if the position is defined for the type parameter symbol before using it. If it's not defined then we log the problem so that we can get a better picture of why the position is undefined.
Commits on Sep 30, 2011
  1. @dotta

    Fixed #1000524, #1000568 and #1000586.

    dotta authored
    ScalaStructureBuilder now correctly expose methods with generic signature to JDT. We use the Scala compiler for generating the java signature from a symbol, since that functionality is already there (call to erasure.javaSig(Symbol)).
    JavaSig class encapsulate the call to erasure.javaSig.
    
    In order to correct mapping of Scala Arrays (ticket #1000586) into Java ones, a new mapType(Type) method has been added to ScalaJavaMapper class. This method is also used to map types in absence of a java signature (which can occur if the method does not have any generic type in its declaration).
    
    All snippet of code that were provided with the tickets have been added to the regression suite. I also had to make some correction to existing tests, particularly for the structurebuilder test named _traits_, as the test's oracle was wrong.
    
    While with this commit we improve a lot interoperability of Java with Scala members, works still has to be done for mapping type parameters of classes. We have an open ticket for that (#1000625), but fixing it should be relatively easy now that we have a good infrastructure for retrieving generic java signature.
Commits on Aug 19, 2011
  1. @dragos

    Updated the code to compile again after deprecated methods were remov…

    dragos authored
    …ed from Scala trunk. Should fix the nightly trunk builds.
Commits on Aug 4, 2011
  1. @dotta

    Removed special treatment of @deprecated annotation as it was useless…

    dotta authored
    … and simply plain wrong
  2. @dotta

    It is better to avoid exposing scala annotation to JDT, as scala anno…

    dotta authored
    …tations cannot be used from Java code.
Something went wrong with that request. Please try again.