| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
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.
|
|\
| |
| | |
SI-9762 Update the REPL to use JLine 2.14.1
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now that we use a release of JLine that includes the fix for:
https://github.com/jline/jline2/issues/208
We no longer need to the workaround introduced in 7719a3c.
Screencast of the still-fixed behaviour:
http://recordit.co/5pzh9OhlQv.gif
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Motivated by the improvements to multi-byte character handling.
Screencast showing the reported bug is fixed:
http://g.recordit.co/ie1Z367NUl.gif
Here's the changelog since JLine 2.12.1:
https://github.com/jline/jline2/compare/jline-2.12.1...jline-2.14.1
I needed to disable a new, on-by-default feature in JLine so that
it didn't add a " " after completing the token `equals` in
`foo.equa<TAB>`.
|
| | |
|
|\ \
| |/
|/| |
Fix erasure for classOf[Unit], don't erase to classOf[BoxedUnit]
|
| | |
|
| |
| |
| |
| | |
Also adds a warning on junit test methods that compile as default
methods.
|
|\ \
| | |
| | | |
Merge 2.11 to 2.12 apr 22
|
| |\ \ |
|
| | | | |
|
| | |\ \
| | | | |
| | | | | |
CI: use java 6 for windows integration
|
| | |/ / |
|
| |\| | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
|
| |\| | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- remove `M2_REPO`. All dependencies are picked up from `build/deps`
- add script to update an existing workspace directory with the required path variables
- add the default Scala library to several projects for better out-of-the-box experience. This means
that changes in the scale-library project may not be visible in the other projects, but makes it
way easier to get a working config. If you really need that, you probably know what you’re doing
anyway.
|
|\ \ \ \
| | | | |
| | | | | |
SI-9684 Deprecate JavaConversions
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Provide higher-priority implicit conversion methods whose names don't
clash with methods in JavaConverters. This allows implicit conversions
to work when importing both JavaConverters._ and JavaConversions._.
|
| | | | | |
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Implicit conversions are now in package convert as ImplicitConversions,
ImplicitConversionsToScala and ImplicitConversionsToJava.
Deprecated WrapAsJava, WrapAsScala and the values in package object.
Improve documentation.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In any shift operation where the lhs is an Int (or smaller) and
the rhs is a Long, the result kind must be Int, and not Long.
This is important because the lhs must *not* be promoted to a
Long, as that causes an opcode for long shift to be emitted.
This uses an rhs modulo 64, instead of int shifts which use an
rhs module 32. Instead, the rhs must be downgraded to an Int.
The new behavior is consistent with the same operations in the
Java programming language.
|
| | | |
|
|\ \ \
| | | |
| | | | |
Remove the duplicate implem of hash codes for numbers.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously, there were two separate implementations of hash
code for boxed number classes:
* One in Statics, used by the codegen of case class methods.
* One in ScalaRunTime + BoxesRunTime, used by everything else.
This commit removes the variant implemented in ScalaRunTime +
BoxesRunTime, and always uses Statics instead. We use Statics
because the one from ScalaRunTime causes an unnecessary module
load.
The entry point ScalaRunTime.hash() is kept, as deprecated,
for bootstrapping reasons.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The two algorithms were different, and could result in different
hash codes for some values, namely, valid long values that were
not also valid int values.
The other two functions `longHash` and `floatHash` are rewritten
to keep a common style with `doubleHash`, but their algorithm
does not change.
|
| | | | |
|
|\ \ \ \
| |_|_|/
|/| | | |
CI: use java 8 for windows integration
|
|/ / / |
|
|\ \ \
| | | |
| | | | |
Ensure ClassBTypes constructed from symbol and classfile are identical
|
| | | |
| | | |
| | | |
| | | |
| | | | |
For some reason this was not the case, leading to spurious inliner
warnings (no inline info found for method O$lzycompute).
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
A super call (invokespecial) to a default method T.m is only allowed if
the interface T is a direct parent of the class. Super calls are
introduced for example in Mixin when generating forwarder methods:
trait T { override def clone(): Object = "hi" }
trait U extends T
class C extends U
The class C gets a forwarder that invokes T.clone(). During code
generation the interface T is added as direct parent to class C. Note
that T is not a (direct) parent in the frontend type of class C.
This commit stores interfaces that are added to a class during code
generation in the InlineInfo classfile attribute. This allows filtering
the interface list when constructing a ClassBType from a classfile.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The code was patched many times in the history and became a bit
scattered.
When emitting a virtual call, the receiver in the bytecode cannot just
be the method's owner (the class in which it is declared), because that
class may not be accessible at the callsite. Instead we use the type
of the receiver. This was basically done to fix
- aladdin bug 455 (9954eaf)
- SI-1430 (0bea2ab) - basically the same bug, slightly different
- SI-4283 (8707c9e) - the same for field reads
In this patch we extend the fix to field writes, and clean up the code.
This patch basically reverts 6eb55d4b, the fix for SI-4560, which was
rather a workaround than a fix. The underlying problem was that in some
cases, in a method invocation `foo.bar()`, the method `bar` was not
actually a member of `foo.tpe`, causing a NoSuchMethodErrors. The
issue was related to trait implementation classes. The idea of the fix
was to check, at code-gen time, `foo.tpe.member("bar")`, and if that
returns `NoSymbol`, use `barSym.owner`. With the new trait encoding
the underlying problem seems to be fixed - all tests still pass
(run/t4560.scala and run/t4560b.scala).
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It tests an internal debugging tool which does not appear to work as
intented. If anyone can compile and run that test and get an output
that looks like the check file, I'd be interested to know. Origins does
not seem to support the kind of stack traces that scalac currently
emits.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In most cases when a class inherits a concrete method from a trait we
don't need to generate a forwarder to the default method in the class.
t5148 is moved to pos as it compiles without error now. the error
message ("missing or invalid dependency") is still tested by t6440b.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
JUnit 4 does not support running `@Test` methods defined as default
methods in parent interfaces. JUnit 5 will, but is not yet available.
Currently scalac emits a forwarder to every trait method inherited by
a class, so tests are correctly executed. The fix for SD-98 will change
this.
|
| | | |
| | | |
| | | | |
The package list is on the right.
|
|\ \ \ \
| |_|/ /
|/| | | |
SI-6710 / PR 5072 follow-up: fix Unit.box / Unit.unbox
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | | |
The backend replaces .box / .unbox methods by corresponding invocations
to BoxesRunTime, but not for Unit.
This commit restores the body of `Unit.box` and `Unit.unbox`.
|
|\ \ \
| | | |
| | | | |
Simplify scala.runtime
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
We can use the normal Scala language constructs instead.
|
| | | |
| | | |
| | | |
| | | | |
Because it was its only call site.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This method was awful. Not only it was using run-time type
tests to essentially encode compile-time overloading. But
it also did 2 slightly different things for the Class case
and ClassTag case.
All in all, it is much more readable to inline the
appropriate implementation at every call site.
|
| | | |
| | | |
| | | |
| | | | |
Because that is the only call site of that method.
|