| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GenBCode is a drop-in replacement for GenASM with several advantages:
- faster: ICode isn't necessary anymore.
Instead, the ASTs delivered by CleanUp (an expression language)
are translated directly into a stack-language (ASM Tree nodes)
- future-proofing for Java 8 (MethodHandles, invokedynamic).
- documentation included, shared mutable state kept to a minimum,
all contributing to making GenBCode more maintainable
than its counterpart (its counterpart being GenICode + GenASM).
A few tests are modified in this commit, for reasons given below.
(1) files/neg/case-collision
Just like GenASM, GenBCode also detects output classfiles
differing only in case. However the error message differs
from that of GenASM (collisions may be show in different order).
Thus the original test now has a flags file containing -neo:GenASM
and a new test (files/neg/case-collision2) has been added
for GenBCode. The .check files in each case show expected output.
(2) files/pos/t5031_3
Currently the test above doesn't work with GenBCode
(try with -neo:GenBCode in the flags file)
The root cause lies in the fix to
https://issues.scala-lang.org/browse/SI-5031
which weakened an assertion in GenASM
(GenBCode keeps the original assertion).
Actually that ticket mentions the fix is a "workaround"
(3) files/run/t7008-scala-defined
This test also passes only under GenASM and not GenBCode,
thus the flags file. GenASM turns a bling eye to:
An AbstractTypeSymbol (SI-7122) has reached the bytecode emitter,
for which no JVM-level internal name can be found:
ScalaClassWithCheckedExceptions_1.E1
The error message above (shown by GenBCode) highlights
there's no ScalaClassWithCheckedExceptions_1.E1 class,
thus shouldn't show up in the emitted bytecode
(GenASM emits bytecode that mentions the inexistent class).
|
| | |
|
| |\
| |
| | |
SI-6309 Test case for early-init / private[this] crasher.
|
| | |
| |
| |
| | |
This has worked since 98daf03, "Overhauled local/getter/setter name logic.".
|
| |\ \
| | |
| | | |
Finalized math.E and math.Pi.
|
| |/ /
| |
| |
| |
| |
| |
| | |
Without this treatment these constants will not be inlined
or folded, bloating bytecode and inhibiting optimization.
Marking them @inline doesn't have any additional effect, but
I did it to futurize them in light of SI-7542.
|
| |\ \
| | |
| | | |
SI-7088 Array crasher in erasure.
|
| | | |
| | |
| | |
| | |
| | | |
The usual business where half our pattern matches are missing
half the necessary cases.
|
| |\ \ \
| |_|/
|/| | |
Revert "SI-6039 Harden against irrelevant filesystem details"
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
This reverts commit b0758f5cb9d966b940933d48bdbb45d17a80de66.
This commit sent startup time through the roof, at least
in some circumstances (it is presumably related to one's
current working directory.)
|
| |\ \
| | |
| | | |
SI-7399 : Take scala.concurrent.context.maxThreads into account
|
| | | |
| | |
| | |
| | |
| | | |
This change fixes the bug whereby specifiying maxThread as a property
has no effect. A small refactoring is applied in the process.
|
| |\ \ \
| | | |
| | | | |
SI-7474 Parallel collections: End the exception handling madness
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
"What's wrong with an API which non-deterministically returns either
type A or type B(Set(A, ...))?"
This is pretty much what the exception handling behavior of the
parallel collections does: If exceptions of type A occur, either an
exception of type A or an exception of type B, wrapping multiple
exceptions of A's, is returned.
This behavior is incredibly broken and so unintuitive, that even
people writing tests don't handle it correctly, as seen in test
files/run/t5375.scala.
Concerning “non-deterministic”:
How many exceptions are observed before the operation is aborted
depends on the machine, the available cores and hyper-threading,
the operating system, the threadpool implementation and
configuration, the size of the collection and the runtime itself.
In fact, files/run/t5375.scala can be made to fail reproducible
on both jdk7u and Avian, if we run on a single-core machine
like in a virtual machine.
With this change, we just pass the "first" exception which occurs.
This is
- consistent with the behaviour of sequential collections,
- doesn't require users to know more about parallel collections
than they already do ("elements might be processed out of order"),
- in line with what Java 8 does.
“Why don't we wrap everything in CompositeThrowables?”
Even consistently returning CompositeThrowable doesn't make much
sense (because we have fail-fast behaviour and don't wait until
all tasks have finished or have thrown an exception).
Therefore, there is no useful semantic in having a
CompositeThrowable which returns "some" exceptions.
I have done extensive research into C#'s approach (which is very
similar to what Scala did until now, but even more messy) and
the key observation from asking multiple C# developers is that
not a single one had understood how PLINQ handled exceptions or
could describe the semantics of it.
As a consequence, either
a) gather and return all exceptions in a CompositeThrowable or
b) just return one, unwrapped,
instead of non-deterministically wrapping a non-deterministic
number of exceptions into a completely unrelated wrapper type.
Considering that changing the parallel collection semantics in
such a profound way as described in a) is out of question, b)
is chosen.
As soon as Scala targets Java > 7 Throwable#addSurpressed can be
used to add further exceptions to the one which gets returned.
This would allow passing more information to the caller without
compromising the simplicity of the API.
|
| |\ \ \ \
| |/ / /
|/| | | |
SI-7502 removing non-existent element from ListMap leaves it unchaged.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Current imperative version constructs a new ListMap regardless of
the fact the map doesn't contain the element. Replace it with the
tail-recursive variant that conserves. Also replace some usages with
the invariant now held.
|
| |\ \ \ \
| |_|_|/
|/| | | |
Make all numeric coercions explicit.
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Optimistically, this is preparation for a day when we don't
let numeric types drift with the winds. Even without the optimism
it's a good idea. It flushed out an undocumented change in
the math package object relative to the methods being forwarded (a
type is widened from what is returned in java) so I documented
the intentionality of it.
Managing type coercions manually is a bit tedious, no doubt,
but it's not tedious enough to warrant abandoning type safety
just because java did it.
|
| |\ \ \
| | | |
| | | | |
Print raw types correctly.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The "For convenience, these are usable as stub implementations"
bit has generated surprisingly few angry letters, but I noticed
today it blows it on raw types. Or, used to blow it.
/** As seen from class Sub, the missing signatures are as follows.
* For convenience, these are usable as stub implementations.
* (First one before this commitw as 'def raw(x$1: M_1)'
*/
def raw(x$1: M_1[_ <: String]): Unit = ???
def raw(x$1: Any): Unit = ???
|
| |\ \ \ \
| |/ / /
|/| | | |
SI-7469 Remove deprecated elements in Java{Conversions,Converters}
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | | |
SI-7410 REPL uses improved tools.jar locator
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The logic in partest for snooping around for tools.jar
is moved to PathResolver, and ILoop uses it from there.
If JAVA_HOME is toolless, check out java.home.
The use case was that Ubuntu installs with `java` at
version 6 and `javac` at version 7; it's easy to wind
up with JAVA_HOME pointing at the version 6 JRE, as
I discovered. It's confusing when that happens.
In future, partest might run under 7 and fork tests
under 6, but those permutations are downstream.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-7003 Partest redirects stderr to log file
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Partest will also read files/filters and files/kind/filters for
filter expressions (one per line, trimmed, leading #comments)
which are taken as regexes.
A test/files/filters is provided which attempts to quell HotSpot
warnings; the test for this commit requires it.
The elided lines can be revealed using the lemon juice of verbosity:
apm@mara:~/projects/snytt/test$ ./partest --verbose --show-diff files/run/t7198.scala
[snip]
>>>>> Transcripts from failed tests >>>>>
> partest files/run/t7198.scala
% scalac t7198.scala
[snip]
% filtering t7198-run.log
--Over the moon
--Java HotSpot(TM) 64-Bit Server VM warning: Failed to reserve shared memory (errno = 28).
The filtering operation is part of the transcript, which is printed on failure.
No attempt is made to be clever about not slurping the filters file a thousand times.
Previous literal patterns had to be updated because there's parens in them thar strings.
Future feature: pattern aliases, define once globally and invoke in test filters.
|
| | | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Some scalac output is on stderr, and it's useful to see that
in the log file, especially for debugging.
Adds a line filter for logs, specified as "filter: pattern"
in the test source.
Backslashes are made forward only when detected as paths.
Test alignments:
Deprecations which do not pertain to the system under test
are corrected in the obvious way.
When testing deprecated API, suppress warnings by deprecating
the Test object.
Check files are updated with useful true warnings, instead of
running under -nowarn.
Language feature imports as required, instead of running under -language.
Language feature not required, such as casual use of postfix.
Heed useful warning.
Ignore broken warnings. (Rarely, -nowarn.)
Inliner warnings pop up under -optimise only, so for now, just
filter them out where they occur.
Debug output from the test required an update.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-7287 include all compiler sources in -src.jar
|
| | |/ / / / |
|
| |\ \ \ \ \
| |/ / / /
|/| | | | |
Concision contribution.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
As noted by reviewer.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We have lots of core classes for which we need not go through
the symbol to get the type:
ObjectClass.tpe -> ObjectTpe
AnyClass.tpe -> AnyTpe
I updated everything to use the concise/direct version,
and eliminated a bunch of noise where places were calling
typeConstructor, erasedTypeRef, and other different-seeming methods
only to always wind up with the same type they would have received
from sym.tpe. There's only one Object type, before or after erasure,
with or without type arguments.
Calls to typeConstructor were especially damaging because (see
previous commit) it had a tendency to cache a different type than
the type one would find via other means. The two types would
compare =:=, but possibly not == and definitely not eq. (I still
don't understand what == is expected to do with types.)
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Try to prevent TypeSymbols from caching a different typeref
for tpe_* and typeConstructor if the symbol is monomorphic.
I find this undesirable:
scala> AnyRefClass.tpe eq AnyRefClass.typeConstructor
res0: Boolean = true
scala> AnyRefClass.tpe eq AnyRefClass.typeConstructor
res1: Boolean = false
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-7499 Additional test case for SI-7319
|
| | | |_|/ /
| |/| | |
| | | | |
| | | | | |
From a duplicate ticket.
|
| |\ \ \ \ \
| |_|/ / /
|/| | | | |
SI-3425 erasure crash with refinement members.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Probably overshot the mark a little.
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Checking that a refinement class symbol does not override
any symbols does mean it will have to be invoke reflectively;
but the converse is not true. It can override other symbols
and still have to be called reflectively, because the
overridden symbols may also be defined in refinement classes.
scala> class Foo { type R1 <: { def x: Any } ; type R2 <: R1 { def x: Int } }
defined class Foo
scala> typeOf[Foo].member(TypeName("R2")).info.member("x": TermName).overrideChain
res1: List[$r.intp.global.Symbol] = List(method x, method x)
scala> res1 filterNot (_.owner.isRefinementClass)
res2: List[$r.intp.global.Symbol] = List()
And checking that "owner.info decl name == this" only works if
name is not overloaded.
So the logic is all in "isOnlyRefinementMember" now, and
let's hope that suffices for a while.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-6811 Deprecate scala.util.parsing.json
|
| | | |/ /
| |/| | |
|
| |\ \ \ \
| |/ / /
|/| | | |
SI-7436 Varargs awareness for super param aliasing.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Don't consider a super class parameter accessor to be
an alias if it is a repeated. Parameter aliases are used
to avoid retaining redundant fields in the subclass; but
that optimization is out of the question here.
|
| |\ \ \ \
| |_|/ /
|/| | | |
Moves AbstractFileClassLoader to scala-reflect.jar
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Its string name was used in ReflectionUtils and became broken after repl
got factored out. This hints that that classloader belongs to where it is
used, i.e. to scala-reflect.jar.
Moreover AbstractFile is defined in scala-reflect.jar, so it's only
logical to also define a derived classloader in scala-reflect.jar.
|
| |\ \ \
| | | |
| | | | |
sanitation of Infer.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Oh exprTypeArgs, you will send us to the poorhouse with
your spendy ways. So many tuples have been dying needlessly.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Only to discover that it's really hard to move isCoercible
anywhere because it wants to call inferView which, despite its
suggestive name, is not visible in Infer. So I did what I
could and documented it a little.
|
