| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| | |
SI-9501 link README to Scala Hacker Guide
|
| | |
|
|\ \
| |/
|/| |
SI-9506 suppress Scala IDE-generated files in the Eclipse project dirs
|
| | |
|
|/ |
|
|\
| |
| | |
SI-9502 Update Eclipse classpaths for scaladoc project.
|
| | |
|
|\ \
| | |
| | | |
get test suite passing on Windows
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
this was causing a mysterious compilation failure on Windows. (it may
not have been a sufficient cause in itself -- which is why I say
"mysterious" -- but in any case, adding the newline made the failure
go away. and besides, the newline should be there. so here it is.)
(it's tempting to make a big commit that fixes this in every
source file. resisting for now)
|
| | |
| | |
| | |
| | | |
includes comment with full details
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
usually it hardly matters, but it's still a bug, and on Windows we
can't delete an open file, so this can cause trouble for someone
writing a test that relies on being able to generate icode files
and then clean them up afterwards. (and in fact, two
IcodeComparison-based tests were failing.)
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
this is mostly intended for .scala files, since because """ preserves
line endings, so we get different results if source files have CRLF.
this was making a few tests fail on Windows (because they used """ to
enclose expected output)
|
|\ \ \
| | | |
| | | | |
tiny fix to spec (pattern matching section)
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
Improve implicits wildcard imports in the IDE
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In 451cab967a, I changed handling of selection of members from
package objects so as to correctly use `somePackage.package.type`
as the prefix, rather than `somePackage`. This fixed generic
substitution for members inherited from superclasses of the
package object.
However, this has subtly changed the scope from which we collect
implicits given a wildcard import. It seems that the IDE gets into
a situation after a scaladoc lookup, which temporarily typechecks
the sources of a package object of a third party library, in which
the members of package object differ from the members of the enclosing
package.
The upshot of this was spurious type errors due to implicit search
discarding an candidate implicit whose symbol is not matched by
typechecking an identifier with the symbol's name at the implicit
usage site (this is how we discard shadowed implicits.)
I'd like to ge to the bottom of this, but in the meantime, I've found
that we can fix the regression by looking up the implicit member
symbols in the package, even while correctly using the package object
as the prefix.
|
|\ \ \ \ \
| |_|_|_|/
|/| | | | |
Avoid using ExecutionContext for Future.sequence of empty collection
|
|/ / / /
| | | |
| | | |
| | | |
| | | | |
Previously _.result() was invoked in the "real" ExecutionContext, but this is an
unnecessary use of the context.
|
|\ \ \ \
| |/ / /
|/| | | |
SI-9495 Add note about configuring Ant for HTTP proxies
|
| |/ / |
|
|\ \ \
| | | |
| | | | |
Fix typo in Process.scala
|
|/ / / |
|
|\ \ \
| |/ /
|/| | |
SI-9029 Fix regression in extractor patterns
|
| | | |
|
| | |
| | |
| | |
| | | |
Found these in an old review branch of mine.
|
| | |
| | |
| | |
| | |
| | | |
It remains from the days of yore, when patterns survived this long
in the compiler.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The unified treatment of classical and named-based pattern matching
does not correctly handle the generalization of "tuple capture".
By "tuple capture", I mean:
```
scala> object Extractor { def unapply(a: Any): Option[(Int, String)] = Some((1, "2")) }
defined object Extractor
scala> "" match { case Extractor(x: Int, y: String) => }
scala> "" match { case Extractor(xy : (Int, String)) => }
warning: there was one deprecation warning; re-run with -deprecation for details
scala> :warnings
<console>:9: warning: object Extractor expects 2 patterns to hold (Int, String) but crushing into 2-tuple to fit single pattern (SI-6675)
"" match { case Extractor(xy : (Int, String)) => }
^
```
Name based pattern matching, new in Scala 2.11, allows one to
deconstruct the elements that structurally resembles `ProductN`:
```
scala> class P2(val _1: Int, val _2: String)
defined class P2
scala> object Extractor { def unapply(a: Any): Option[P2] = Some(new P2(1, "2")) }
defined object Extractor
scala> "" match { case Extractor(x: Int, y: String) => }
```
However, attempting to extract the `P2` in its entirety leads to
an internal error:
```
scala> "" match { case Extractor(p2: P2) => }
<console>:10: warning: fruitless type test: a value of type (Int, String) cannot also be a P2
"" match { case Extractor(p2: P2) => }
^
<console>:10: error: error during expansion of this match (this is a scalac bug).
The underlying error was: type mismatch;
found : P2
required: (Int, String)
"" match { case Extractor(p2: P2) => }
^
```
Note that this match was legal and warning free in 2.10.
This commit avoids the hard-coded assumption that the "tuple capture"
results in a `TupleN`, and instead keeps track of the product-ish
type from which we extracted the element types. I have also opted not
to limit the deprecation warning to `TupleN` extractors.
|
|\ \ \
| | | |
| | | | |
add support for MSys2 to bin/scala shell script
|
| | | | |
|
| | | | |
|
|\ \ \ \
| |_|_|/
|/| | | |
fix indentation
|
| | | |
| | | |
| | | |
| | | | |
this sneaked into 2d025fe2d0c9cd0e01e390055b0531166988f901
|
|\ \ \ \
| |/ / /
|/| | | |
Improvements to REPL completion for annotations and string interpolation
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
A trio of problems were hampering autocompletion of annotations.
First, given that that annotation is written before the annotated
member, it is very common to end parse incomplete code that has a
floating annotation without an anotatee.
The parser was discarding the annotations (ie, the modifiers) and
emitting an `EmptyTree`.
Second, the presetation compiler was only looking for annotations
in the Modifiers of a member def, but after typechecking annotations
are moved into the symbol.
Third, if an annotation failed to typecheck, it was being discarded
in place of `ErroneousAnnotation`.
This commit:
- modifies the parser to uses a dummy class- or type-def tree,
instead of EmptyTree, which can carry the annotations.
- updates the locator to look in the symbol annotations of the
modifiers contains no annotations.
- uses a separate instance of `ErroneousAnnotation` for each
erroneous annotation, and stores the original tree in its
`original` tree.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In the code:
```
s"${fooo<CURSOR"
```
The parser treats `fooo` as a interpolator ID for the quote that
we actually intend to end the interpolated string.
Inserting a space (in addition to `__CURSOR__` that we already
patch in to avoid parsing a partial identifier as a keyword),
solves this problem.
|
|\ \ \
| | | |
| | | | |
[backport] SI-9375 add synthetic readResolve only for static modules
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For inner modules, the synthetic readResolve method would cause the
module constructor to be invoked on de-serialization in certain
situations. See the discussion in the ticket.
Adds a comprehensive test around serializing and de-serializing
modules.
|
|\ \ \
| | | |
| | | | |
bump required Ant version in README.md
|
|/ / /
| | |
| | |
| | |
| | | |
(a little missing piece of https://github.com/scala/scala/pull/4746
we missed at review time)
|
|\ \ \
| | | |
| | | | |
Topic/completely 2.11
|
| | | | |
|
| |\ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Before:
```
scala> {" ".char<TAB>}
charAt chars
scala> {" ".char<CURSOR>}}
```
I noticed that pressing <SPACE>-<BACKSPACE> re-rendered the line
correctly, so I've added this workaround to our customization of
the JLine console reader.
After:
```
scala> {" ".char<TAB>}
charAt chars
scala> {" ".char<CURSOR>}
```
We can delete this workaround when JLine 2.13.1 is released, but
I haven't heard back about when this might happen.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Recover part of the identifier that preceded the cursor from the
source, rather than from the name in the `Select` node, which might
contains an encoded name that differs in length from the one in
source.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I'm pretty sure the `isSynthetic` call added in 854de25ee6 should
instead be `isArtifact`, so that's what I've implemented here.
`isSynthetic` used to also filter out error symbols, which are
created with the flags `SYNTHETIC | IS_ERROR`. I've added an addition
test for `isError`, which was needed to keep the output of
`presentation/scope-completion-import` unchanged.
The checkfile for `presentation/callcc-interpreter` is modified to
add the additional completion proposals: synthetic companion objects.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When `foo.<TAB>`, assume you don't want to see the inherited members
from Any_ and universally applicable extension methods like
`ensuring`. Hitting <TAB> a second time includes them in the results.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We need to include the previously entered lines into the code
that we presentation compile.
Management of this state makes the interpret method non tail
recursive, so we could blow the default stack with a multi-line entry
of hundreds of lines. I think thats an acceptable limitation.
|