| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
just in time for Halloween. "boostrap" is definitely the most
adorable typo evah -- and one of the most common, too. but we don't
want to scare anybody.
|
| | |
|
| |
|
|
|
| |
- Remove unused references to "addTargetMethods"
- Require that `targetMethodMap` is provided
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old design allowed a forged `SerializedLambda` to be
deserialized into a lambda that could call any private method
in the host class.
This commit passes through the list of all lambda impl methods
to the bootstrap method and verifies that you are deserializing
one of these.
The new test case shows that a forged lambda can no longer call
the private method, and that the new encoding is okay with a large
number of lambdas in a file.
We already have method handle constants in the constant pool
to support the invokedynamic through LambdaMetafactory, so
the only additional cost will be referring to these in
the boostrap args for `LambdaDeserialize`, 2 bytes per lambda.
I checked this with an example:
https://gist.github.com/retronym/e343d211f7536d06f1fef4b499a0a177
Fixes SD-193
|
| |
|
|
|
| |
Consolated JUnit tests and heeded comment about private def and
code beauty.
|
| |
|
|
| |
Because it is otherwise unused.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In method `ScalaRuntime.stringOf(arg: Any, maxElements: Int)` there are
`case x: Iterable[_]` and `case x: ParIterable[_]` which have the excat
same code that only uses the `GenIterable[_]` API on `x`. Therfore they
can be replaced by a single `case x: GenIterable[_]`.
The `case x: ParIterable[_]` was added because prevoiusly parallel
colections would only match `case x = x.toSting()` which ignores the
`maxElements` parameter. This was still the case for other `GenIterable[_]`.
Using `case x: GenIterable[_]` will cover those cases as well.
This change is required for Scala.js compatibility as it does not
support parallel collections.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit e1895d64f87dc3c699a3ccbc8a3143b18d3b5bb1,
titled "Add scala-java8-compat to scala-library.jar".
Move SAM functions and `LambdaDeserializer` (from scala/scala-java8-compat@9253ed9)
into `scala.runtime.java8` package under `src/library`.
(The package name is the only diff -- they were in `scala.compat.java8` before).
The original LambdaDeserializer:
https://github.com/scala/scala-java8-compat/blob/c0732e6/src/main/java/scala/compat/java8/runtime/LambdaDeserializer.scala
|
|
|
Not every application will force these in a single thread; we
have to do our best to avoid cycles between them.
The enclosed test was failing every time before the change.
This commit breaks the cycle by avoiding computing `tupleNames`
in the constructor of `ScalaRuntime`. The new version has the
added benefit of including specialized tuple subclasses, which
is verified with a unit test for `isTuple`.
Are there more of these lurking? It seems likely. I'm more than
a little concerned about the way the `ControlThrowable` fires up
`scala.SystemProperties` to check whether or not to suppress
stack traces; there is already an ugly hack in place:
object NoStackTrace {
final def noSuppression = _noSuppression
// two-stage init to make checkinit happy,
// since sys.SystemProperties.noTraceSupression.value
// calls back into NoStackTrace.noSuppression
final private var _noSuppression = false
_noSuppression = sys.SystemProperties.noTraceSupression.value
}
|
