| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add operations like map, flatMap which assume right-bias
- Deprecate {Left,Right}Projection
- Deprecate left and right in favor of swap
- Add contains, toOption, toTry, toSeq and filterOrElse
- toSeq returns collection.immutable.Seq instead of collection.Seq
- Don't add get
There are no incompatible changes.
The only possibility of breakage that exists is when people have added
extension methods named map, flatMap etc. to Either in the past doing
something different than the methods added to Either now.
One detail that moved the scales in favor of deprecating LeftProjection
and RightProjection was the desire to have toSeq return
scala.collection.immutable.Seq instead of scala.collection.Seq
like LeftProjection and RightProjection do.
Therefore keeping LeftProjection and RightProjection would introduce
inconsistency.
filter is called filterOrElse because filtering in a for-comprehension
doesn't work if the method needs an explicit argument.
contains was added as safer alternative to
if (either.isRight && either.right.get == $something) ...
While adding filter with an implicit zero value is possible, it's
dangerous as it would require that developers add a "naked" implicit
value of type A to their scope and it would close the door to a future
in which the Scala standard library ships with Monoid and filter could
exist with an implicit Monoid parameter.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implements the necessary tests to check if a method with an
InvokeDynamic instruction can be inlined into a destination class.
Only InvokeDynamic instructions with LambdaMetaFactory as bootstrap
methods can be inlined. The accessibility checks cannot be implemented
generically, because it depends on what the bootstrap method is doing.
In particular, the bootstrap method receives a Lookup object as
argument which can be used to access private methods of the class
where the InvokeDynamic method is located.
A comment in the inliner explains the details.
|
| |
|
|
|
|
|
| |
No change in build.sbt, there's no optimizer settings there yet.
Ignore the inliner warning in presentation/t7678 and run/t8029.scala,
noted in https://issues.scala-lang.org/browse/SI-9378
|
|
|
It we can only safely use vals in Definitions for top-level symbols.
Otherwise, when the IDE switches to loading the symbol from source,
we can hold on to a stale symbol, which in turn impedes implicit
materialization of TypeTags.
This commit moves (most) of the accessors for member symbols
into RunDefinitions, and changes calling code accordingly.
This is a win for presentation compiler correctness, and
might even shave of a few cycles.
In a few cases, I have had to leave a `def` to a member symbol
in Definitions so we can get to it from the SymbolTable cake,
which doesn't see RunDefinitions.
The macro FastTrack facility now correctly recreates the mapping
from Symbol to macro implementation each run, using a new facility
in perRunCaches to create a run-indexed cache.
The enclosed test recreates the situation reported in the ticket,
in which TypeTags.scala is loaded from source.
|
