| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Under `-Yrepl-class-based`, templating must follow the same scoping
as under traditional object-based. The new test shows a typical
case where two values of the same simple name must be imported in
different scopes.
|
| |
|
|
|
| |
Under `-Yrepl-class-based`, imports from historical `$read`
instances must be singleton-typed so that path-dependent types
remain so.
|
| |
|
|
|
| |
When constructing code text for compilation, the REPL
should prefer standard escape sequences, in case unicode
escapes are disabled.
|
| |
|
|
| |
Includes tests to verify the toString representations.
|
| |
|
|
|
|
|
|
| |
During code review for the fix for SI-9546, we found a corner
case in the SI-9425 that remained broken.
Using `finalResultType` peels off all the constructor param
lists, and solves that problem.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In SI-9425, I disabled the rewrite of `CaseClass.apply(x)` to
`new CaseClass(x)` if the constructor was was less accessible
than the apply method. This solved a problem with spurious
"constructor cannot be accessed" errors during refchecks for
case classes with non-public constructors.
However, for polymorphic case classes, refchecks was persistent,
and even after refusing to transform the `TypeApply` within:
CaseClass.apply[String]("")
It *would* try again to transform the enclosing `Select`, a
code path only intended for monomorphic case classes. The tree has
a `PolyType`, which foiled the newly added accessibility check.
I've modified the call to `isSimpleCaseApply` from the transform
of `Select` nodes to exclude polymorphic apply's from being
considered twice.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've identified a dead call to `transformCaseApply` that
seems to date back to Scala 2.6 vintages, in which case
factory methods were a fictional companion method, rather
than a real apply method in a companion module.
This commit adds an abort in that code path to aide code
review (if our test suite still passes, we know that I've
removed dead code, rather than silently changing behaviour.)
The following commit will remove it altogether
I then inlined a slightly clunky abstraction in the two
remaining calls to `transformCaseApply`. It was getting in the
way of a clean fix to SI-9546, the topic of the next commit.
|
| |
|
|
|
|
| |
Conflicts:
test/files/pos/t3420.flags
versions.properties
|
| |\
| |
| | |
SI-9623 Avoid unnecessary hasNext calls in JoinIterator & ConcatIterator
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These iterator implementations are used to concatenate two (JoinIterator)
or more (ConcatIterator) other iterators with `++`. They used to perform
many unnecessary calls to the child iterators’ `hasNext` methods.
This improved state machine-based implementation reduces that number to
the bare minimum, i.e. iterating over concatenated iterators with
`foreach` calls the children's `hasNext` methods a total of (number of
children) + (number of elements) times, the same as when iterating over
all children separately.
|
| |\ \
| | |
| | | |
SI-9572 Check for illegal tuple sizes in the parser
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit adds explicit checks with syntax errors for tuple literals
and types of more than 22 elements. An alternative approach to fixing
SI-9572 would be to revert to the old failure mode of Scala 2.10 where
references to arbitrary `scala.TupleXY` would be generated in the
parser, which then leads to “type/object not found” errors in the
typechecker. This fix here is more intrusive but arguably provides a
better user experience.
Methods `stripParens` and `makeBinop` are moved from `TreeBuilder` to
`Parsers` because they can now generate syntax errors. New methods
`makeSafeTupleType` and `makeSafeTupleTerm` implement the error checking
on top of `makeTupleType` and `makeTupleTerm`. They are overridden with
no-op versions in the quasiquotes parser because it also overrides `makeTupleType` and `makeTupleTerm` in a way that supports arbitrary tuple sizes.
|
| |/
|
|
|
|
|
|
| |
Calling `wrap` or one of the higher-dimension Array factory methods on
the `Manifest` for `Unit` led to an exception because it tried to use
`void` as a primitive type. Unlike all other primitive Scala types,
`Unit` needs to be boxed. The basic `newArray` method was not affected
by this bug because it was already special-cased. The fix is to also
special-case `arrayClass`.
|
| |
|
|
|
|
|
|
|
|
| |
1. Replace option handling with library call
2. Remove NumberFormatException catch presumed to be copy/paste legacy
3. It's Scaladoc
4. Parse trailing whitespace regex once instead of per line
5. Use string interpolation where it improves readability
6. Add missed alternative to block grammar production rule
7. Add regression test for tag requirement warnings
|
| |\
| |
| | |
[backport] SI-9616 False positive in unused import warning
|
| | |
| |
| |
| | |
This is a minimal backport of the fix for SI-9383.
|
| | |
| |
| |
| | |
see https://github.com/scala/scala-dev/issues/72 for details
|
| |/
|
|
| |
Binary search should be used for every `IndexedSeqLike` instance and not only for `IndexedSeq`. According the Scaladoc, it is `IndexedSeqLike` that guarantees "constant-time or near constant-time element access and length computation".
|
| |\
| |
| | |
SI-9567 Fix pattern match on 23+ param, method local case class
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Typechecking constructor patterns of method local case classes
was only working because of the existence of the unapply method
in the companion, which is used if navigation to the case class
companion object fails.
We now support defintion of, and pattern matching on, case classes
with more than 22 parameters. These have no `unapply` method
in the companion, as we don't have a large enough tuple type to
return. So for such case classes, the fallback that we inadvertently
relied on would no longer save us, and we'd end up with a compile
error advising that the identifier in the constructor pattern was
neither a case class nor an extractor.
This is due to the propensity of `Symbol#companionXxx` to return
`NoSymbol` when in the midst of typechecking. That method should
only be relied upon after typechecking. During typechecking,
`Namers#companionSymbolOf` should be used instead, which looks in the
scopes of enclosing contexts for symbol companionship. That's
what I've done in this commit.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Under -optimize, the pattern matcher tries to avoid local variables
in favour of directly accessing to non-var case class accessors.
However, the code that analysed the patterns failed to account
properly for repeated parameters, which could either lead to
a compiler crash (when assuming that the n-th subpattern must have
a corresponding param accessor), or could lead to a correctness
problem (when failing to eagerly the bound elements from the
sequence.)
The test case that tried to cover seems only to have been working
because of a separate bug (the primary subject of SI-9567) related
to method-local case classes: they were treated during typechecking
as extractors, rather than native case classes.
The subsequent commit will fix that problem, but first we must
pave the way with this commit that emits local vals for bound
elements of case class repeated params.
|
| |\ \
| | |
| | | |
SI-9581 Fix overflow on Vector take and drop methods
|
| | |/
| |
| |
| |
| |
| | |
Fixes the index/length comparison in `Vector#take` and `Vector#drop` so that they handle all possible integer values.
Given the collection's invariants `startIndex >= endIndex` and `0 >= startIndex, endIndex`, it is sufficient to change the arithmetic in the comparison as done in this commit to avoid overflows. As cases when `n <= 0` are handled beforehand, `endIndex - n` cannot overflow, contrary to `startIndex + n`. If without the danger of overflows the condition yields true, on the other hand, `startIndex + n` cannot overflow as it is smaller than `endIndex` (as the previous formulation of the condition shows).
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
- Fix the scoping of files/lib/*.jar. These files were not on the
classpath when running partest from sbt.
- Pass the same standard Java options to partest as from the command
line. This requires new versions of scala-partest and
scala-partest-interface.
- Fix the classpath scanning in jvm/innerClassEnclMethodJavaReflection.
It only worked for JARs and relative directories but not for absolute
directory paths (which are produced by sbt).
|
| |\
| |
| | |
Attacking exponential complexity in TypeMaps
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Don't normalize existentials during the `contain`-s type map;
`ExistentialType#normalize' calls contains internally and
an exponential blowup ensues.
- Ensure that the type map used in variance validation never
returns modified types in order to avoid needless cloning of
symbols.
The enclosed test case still gets stuck in Uncurry, thanks to
the way that `TypeMap#mapOver(List[Symbol])` recurses through the
type first to check whether the type map would be an no-op or not.
If not, it repeats the type map with cloned symbols. Doing the work
twice at each level of recursion blows up the complexity.
Removing that "fast path" allows the enclosed test to compile
completely. As at this commit, it gets stuck in uncurry, which
dealiases `s.List` to `s.c.i.List` within the type.
Some more background on the troublesome part of `TypeMap`:
http://lrytz.github.io/scala-aladdin-bugtracker/displayItem.do%3Fid=1210.html
https://github.com/scala/scala/commit/f8b2b21050e7a2ca0f537ef70e3e0c8eead43abc
|
| |\ \
| | |
| | | |
less confusing wording for a dependent method type error
|
| | |/
| |
| |
| |
| |
| |
| |
| | |
note to reviewers: the error messages in this file are over the place
about whether they're called "parameter sections", or "argument
lists", or what, so there's no point in being picky about that here
for context see SI-823
|
| |\ \
| | |
| | | |
Multi output problem with delambdafied compilation
|
| | |/ |
|
| |\ \
| | |
| | | |
it's Scaladoc, not ScalaDoc
|
| | |/
| |
| |
| |
| | |
renaming the existing ScalaDoc and ScalaDocReporter classes might
break stuff, sadly, but at least we can fix the rest
|
| |\ \
| | |
| | | |
SI-9497 Fix SetLike#clear() default implementation
|
| | | |
| | |
| | |
| | | |
When dealing with mutable collections, it is not safe to assume iterators will remain consistent when the collection is modified mid-traversal. The bug reported in SI-9497 is very similar to SI-7269, "ConcurrentModificationException when filtering converted Java HashMap". Then, only the `retain` method was fixed. This commit fixes `clear`, which had the same problem.
|
| |\ \ \
| |_|/
|/| | |
[SI-9503] Deprecate scala.collection.immutable.PagedSeq
|
| | | | |
|
| | |/
|/|
| |
| |
| |
| | |
A session test with extra filtering best expresses the intentions.
No check file is required.
|
| |\ \
| |/
|/| |
improvements to Windows build & test situation
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
this was failing because the expected output was:
res1: List[String] = List(shello, world.)
but the actual output was:
res1: List[String] = List(shello, world., Picked up _JAVA_OPTIONS: -Duser.home=y:\jenkins)
but the "Picked up..." part caused partest's filters feature to
ignore the entire line (it doesn't anchor matches to start of line.)
This was a tough one to track down.
|
| |\ \
| | |
| | | |
SI-9513 decrement "deleted" count in OpenHashMap.put() when slot reused
|
| | | | |
|
| | |/ |
|
| |\ \
| |/
|/| |
SI-9492 REPL paste here doc
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Simple here documentish syntax for REPL paste.
This makes it easier to paste a block of script
(as opposed to transcript).
It also means you won't accidentally ctl-D out
of the REPL and then out of SBT and then out of
the terminal window.
```
scala> :paste < EOF
// Entering paste mode (EOF to finish)
class C { def c = 42 }
EOF
// Exiting paste mode, now interpreting.
defined class C
scala> new C().c
res0: Int = 42
scala> :paste <| EOF
// Entering paste mode (EOF to finish)
|class D { def d = 42 }
EOF
// Exiting paste mode, now interpreting.
defined class D
scala> new D().d
res1: Int = 42
scala> :quit
```
|
| |\ \
| |/
|/| |
SI-9029 Fix regression in extractor patterns
|
| | |
| |
| |
| | |
Found these in an old review branch of mine.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
