| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rewrite tests for new optimizer
- SI-6941
- SI-2171
- t3430
- t3252
- t4840
- t2171
- t3430
- t3252
- t6157
- t6547
- t8062
- t8306
- t8359
- t9123
- trait-force-info
- private-inline
test cases for bugs fixed in the new optimizer
- SI-9160, the unnecessary boxing mentioned in the ticket is optimzied
since push-pop elimination (#4858).
- SI-8796
- SI-8524
- SI-7807
fix flags file for t3420
remove an empty flags file
remove unnecessary partest filters
explicit inliner warnings in test t7582
Restore the lisp test. Removing the flags file - our build runs with the
(new) optimizer enabled anyway.
The test spent the past few years as an optimizer test in pos/
see https://issues.scala-lang.org/browse/SI-4512. The attempt may fail,
but why not give it a try.
$ git lg -S"lisp"
...
| * | | | f785785 - SI-4579 Yoke the power of lisp.scala as a stress for the optimizer. (3 years, 8 months ago) <Jason Zaugg>
...
* | | | | | | 622cc99 - Revert the lisp test. (3 years, 10 months ago) <Paul Phillips>
...
* | | | | | | 97f0324 - Revived the lisp test. (3 years, 10 months ago) <Paul Phillips>
...
* | 1e0f7dc - Imprison the lisp test, no review. (4 years, 4 months ago) <Paul Phillips>
...
* | 6b09630 - "Freed the lisp test." Tweaked partest defaults... (4 years, 6 months ago) <Paul Phillips>
...
* | fec42c1 - Lisp test wins again, no review. (4 years, 8 months ago) <Paul Phillips>
...
* | 1c2d44d - Restored the lisp.scala test. (4 years, 8 months ago) <Paul Phillips>
...
* | 15ed892 - Temporarily sending lisp.scala to be interprete... (4 years, 8 months ago) <Paul Phillips>
...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move run/t8960 to pending
It tests the serialVersionUID field on closure classes. The field
doesn't exist for indyLambda closures.
See https://issues.scala-lang.org/browse/SI-9373
Move some reify tests to pending
They fail at runtime in GenBCode since scala is built with indyLambda
enabled:
java.lang.AssertionError: assertion failed: Bad superClass for trait JFunction1: class Any
at scala.tools.nsc.Global.assert(Global.scala:261)
at scala.tools.nsc.backend.jvm.BTypesFromSymbols.setClassInfo(BTypesFromSymbols.scala:228)
Noted in https://issues.scala-lang.org/browse/SI-9374
force t6546 to GenASM - no closure elimination in GenBCode yet
Noted in https://issues.scala-lang.org/browse/SI-9364.
Fix or disable some tests that fail because of the old optimizer
The old inliner fails more often when the library is built with
indylambda.
Noted in https://issues.scala-lang.org/browse/SI-9374.
Example: List.foreach
➜ sandbox git:(jfun) ✗ qs -Ybackend:GenASM -optimize -Yinline-warnings
Welcome to Scala version 2.12.0-20150630-220939-1cb032d806 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_45).
Type in expressions to have them evaluated.
Type :help for more information.
scala> List(1,2,3).foreach(x => x + 1)
<console>:11: warning: Could not inline required method foreach because bytecode unavailable.
List(1,2,3).foreach(x => x + 1)
^
<console>:11: warning: At the end of the day, could not inline @inline-marked method foreach
List(1,2,3).foreach(x => x + 1)
^
Upate a number of tests for having indyLambda enabled
The delambdafyLambdaClassNames tests was removed, there's nothing to
tests with indyLambda.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It’s almost 1am, so I’m only scratching the surface, mechanistically
applying the renames that I’ve written down in my notebook:
* typeSignature => info
* declarations => decls
* nme/tpnme => termNames/typeNames
* paramss => paramLists
* allOverriddenSymbols => overrides
Some explanation is in order so that I don’t get crucified :)
1) No information loss happens when abbreviating `typeSignature` and `declarations`.
We already have contractions in a number of our public APIs (e.g. `typeParams`),
and I think it’s fine to shorten words as long as people can understand
the shortened versions without a background in scalac.
2) I agree with Simon that `nme` and `tpnme` are cryptic. I think it would
be thoughtful of us to provide newcomers with better names. To offset
the increase in mouthfulness, I’ve moved `MethodSymbol.isConstructor`
to `Symbol.isConstructor`, which covers the most popular use case for nme’s.
3) I also agree that putting `paramss` is a lot to ask of our users.
The double-“s” convention is very neat, but let’s admit that it’s just
weird for the newcomers. I think `paramLists` is a good compromise here.
4) `allOverriddenSymbols` is my personal complaint. I think it’s a mouthful
and a shorter name would be a much better fit for the public API.
|
| |
|
|
|
|
|
|
|
|
| |
Performs the following renamings:
* scala.reflect.macros.BlackboxContext to scala.reflect.macros.blackbox.Context
* scala.reflect.macros.BlackboxMacro to scala.reflect.macros.blackbox.Macro
* scala.reflect.macros.WhiteboxContext to scala.reflect.macros.whitebox.Context
* scala.reflect.macros.WhiteboxMacro to scala.reflect.macros.whitebox.Macro
https://groups.google.com/forum/#!topic/scala-internals/MX40-dM28rk
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first commit in the series. This commit only:
1) Splits Context into BlackboxContext and WhiteboxContext
2) Splits Macro into BlackboxMacro and WhiteboxMacro
3) Introduces the isBundle property in the macro impl binding
Here we just teach the compiler that macros can now be blackbox and whitebox,
without actually imposing any restrictions on blackbox macros. These
restrictions will come in subsequent commits.
For description and documentation of the blackbox/whitebox separation
see the official macro guide at the scaladoc website:
http://docs.scala-lang.org/overviews/macros/blackbox-whitebox.html
Some infrastructure work to make evolving macros easier:
compile partest-extras with quick so they can use latest library/reflect/...
|
| | |
|
|
|
As per Jason's comment: How are Scala classes containing @throws annots
treated? I can't figure out whether we pickle the annotation in addition
to adding the exception to the signature. If we do, might we end up with
duplicate annotations in runtime reflection? This warrants a test.
See the context of the discussion here: https://github.com/scala/scala/pull/2040/files#r2874769.
No, we won't end up with duplicates, because classes defined in Scala
are loaded in a different completer. But I'll add a test - you can never
have too many of those.
|
