| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Consolated JUnit tests and heeded comment about private def and
code beauty.
|
|
|
|
|
|
|
|
|
|
| |
Probably there should be an Abide rule to avoid leaking
the "underlying value" of a value class. The spec or SIP defines
"underlying type" but doesn't mention the underlying value.
The argument for concealing the member is that it is redundant
and makes autocompletion results harder to read. Also, possibly
an additional implicit might want to add a member so-named.
|
|\
| |
| | |
SI-8044 Allow binding backquoted varid in patterns
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Allows arbitrary identifier in `X @ pat`, including
non-varids. This goes to regularity.
Users of this syntax are not likely to be confused
by the "backquoted var id is stable" rule.
Also for sequence pattern, `X @ _*`.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, a varid could not be backquoted, so that it was not
possible to introduce variables with names such as `type` in a
match expression.
This commit allows backquoted varids in `case x @ _` and
`case x: Int`. In neither position is a stable id accepted,
that is, an id with leading uppercase.
Therefore, this commit merely relaxes the backquoted varid to
be taken as a normal varid in these contexts.
|
|\ \
| | |
| | | |
SI-9656 Distinguish Numeric with step type
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For Range and NumericRange, toString will indicate the step
if it is not 1.
Additionally, indicate empty ranges and ranges which are not
"exact".
For a "mapped" range, used by `Range.Double`, toString
includes the underlying range and the simple type of the step
(to distinguish Double from BigDecimal).
|
|\ \ \
| | | |
| | | | |
Check left side of an assignment expression for errors; fixes SI-9781
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`convertToAssignment` is triggered on a type error but it doesn't seem
to really care what the error is as long as the expression can be
converted to an assignment expression.
This patch fixes that by checking whether the qualifier of the selection
contains any errors before deciding to continue with the conversion.
|
|\ \ \
| | | |
| | | | |
SI-9760 Fix for higher-kinded GADT refinement
|
| | | | |
|
| | | | |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
SI-9776 Fix type of PriorityQueue.newBuilder and improve performance
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
- Fix the return type of mutable.PriorityQueue.newBuilder to be
Builder[A, PriorityQueue[A]] rather than PriorityQueue[A].
- Improve performance of bulk inserts from O(N log N) to O(N),
primarily in the builder, ++=, and reverse. These changes
indirectly benefit the many other methods that use the builder or ++=.
- Improve performance of clone.
- Fix SI-9757 space leak in dequeue.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Improve Future documentation (+ minor code cleanups)
|
| | | | | | |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-9121 test case (fixed in new optimizer), SI-9179 test case
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Also adds a mising phase travel in the backend. A comment already
points out why it's necessary, but it was actually forgotten.
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-9361 fixed assert allowing display of improved error message.
|
| | | | | | | | |
|
|\ \ \ \ \ \ \ \
| |_|/ / / / / /
|/| | | | | | | |
SI-5463 Check .jars before using them
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Make broken JAR files on compiler classpath cause a fatal error
|
|\ \ \ \ \ \ \ \
| |_|_|_|/ / / /
|/| | | | | | | |
Clean up JUnit tests, make sure they pass without bootstrap [ci: last-only]
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Test classes not ending in "Test" are not executed in sbt. IntelliJ
runs them.
After this patch: 803 tests executed both in sbt and junit.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | |_|_|_|/ /
| |/| | | | | |
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-9665 Backquoted vbar in extractor pattern
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Allow an infix extractor named `|`, when backquoted.
|
| |/ / / / / /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Refactor the ScriptEngine support to an adaptor atop the
IMain API.
Allow references to resolve to context attributes. (The
attributes must be defined at compilation time, though
they may resolve to updated values at evaluation time.)
This means that attributes are not bound statically in
REPL history. In particular, we forgo the trick of binding
attributes named "name: Type" as typed values.
Instead, an `x` bound in dynamic context is injected into
the script as a dynamic selection `$ctx.x` where `ctx`
performs the look-up in the script context.
When a compiled script is re-evaluated, a new instance of
the script class is created and defined symbols are
rebound.
The context stdout writer is handled with `Console.withOut`,
with bytes decoded using the default charset.
Compilation errors are thrown as ScriptException with the
first reported error.
This commit doesn't attempt dynamic selection from objects
in context. Currently, script must cast.
|
| | | | | | |
| | | | | | |
| | | | | | | |
Test for SI-7088, arrays containing tagged primitives
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-9671, SI-7397 fix null.asInstanceOf[Int] when pt erases to Object
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Erasure first replaces null.asInstanceOf[Int] by unbox(null). If the
expected type erases to object, erasure then introduces a box operation,
yielding box(unbox(null)). Note that this value is a box of zero, not
null.
Erasure has an optimization to replace box(unbox(x)) in case x is
of primitive type. 60f1b4b extended this to the case when x is null,
which is incorrect in general. The reason was to prevent creating a
primitive box to be stored in the unused generic field when creating
an instance of a specialized class. A special case ensures that this
optimization is still performed.
|
|/ / / / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
We used to disable generation of static forwarders when a object had a
trait as a companion, as one could not add methods with bodies to an
interface in JVM 6.
The JVM lifted this restriction to support default methods in interfaces,
so we can lift the restriction on static forwarders, too.
Fixes https://github.com/scala/scala-dev/issues/59
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Java generic signature generation was making the wrong
assumption about how refinement types should erase to
Java generics.
This commit passes through the current value of `primitiveOk`,
rather than forcing it to `true`.
This flag is true when generating the signature for `f2`,
but false in `i2` (as we are in a type argument position).
|
| |_|_|_|_|/
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Java generic signatures assume that refinement types
should be boxed.
Why did `g2` in the test seem to be immune to this bug
demonstrated by `f2`? Because we opt to elide the generic
signature altogether when no generics are involved.
|
|\ \ \ \ \ \
| |_|/ / / /
|/| | | | | |
Improve performance and behavior of ListMap and ListSet
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
ListSet and ListMap are two collections which share the exact same internal structure. This commit makes the two approaches as similar as possible by renaming and reordering internal methods, improving their Scaladoc and their code style. The Scaladoc of the classes and companion objects is also improved in order to alert users of the time complexity of the collections' operations.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Makes the immutable `ListMap` and `ListSet` collections more alike one another, both in their semantics and in their performance.
In terms of semantics, makes the `ListSet` iterator return the elements in their insertion order, as `ListMap` already does. While, as mentioned in SI-8985, `ListMap` and `ListSet` doesn't seem to make any guarantees in terms of iteration order, I believe users expect `ListSet` and `ListMap` to behave in the same way, particularly when they are implemented in the exact same way.
In terms of performance, `ListSet` has a custom builder that avoids creation in O(N^2) time. However, this significantly reduces its performance in the creation of small sets, as its requires the instantiation and usage of an auxilliary HashSet. As `ListMap` and `ListSet` are only suitable for small sizes do to their performance characteristics, the builder is removed, the default `SetBuilder` being used instead.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
merge/2.11.x-to-2.12.x-20160517
Conflicts:
build.sbt
test/files/run/repl-javap-app.check
test/files/run/repl-javap-app.scala
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|