| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Issue precise warnings when the inliner fails to inline or analyze a
callsite. Inline failures may have various causes, for example because
some class cannot be found on the classpath when building the call
graph. So we need to store problems that happen early in the optimizer
(when building the necessary data structures, call graph, ClassBTypes)
to be able to report them later in case the inliner accesses the
related data.
We use Either to store these warning messages. The commit introduces
an implicit class `RightBiasedEither` to make Either easier to use for
error propagation. This would be subsumed by a biased either in the
standard library (or could use a Validation).
The `info` of each ClassBType is now an Either. There are two cases
where the info is not available:
- The type info should be parsed from a classfile, but the class
cannot be found on the classpath
- SI-9111, the type of a Java source originating class symbol cannot
be completed
This means that the operations on ClassBType that query the info now
return an Either, too.
Each Callsite in the call graph now stores the source position of the
call instruction. Since the call graph is built after code generation,
we build a map from invocation nodes to positions during code gen and
query it when building the call graph.
The new inliner can report a large number of precise warnings when a
callsite cannot be inlined, or if the inlining metadata cannot be
computed precisely, for example due to a missing classfile.
The new -Yopt-warnings multi-choice option allows configuring inliner
warnings.
By default (no option provided), a one-line summary is issued in case
there were callsites annotated @inline that could not be inlined.
|
| | |
|
| |
|
|
|
|
|
| |
Given that in 2.11 we have upgraded our name construction facility
from `newTxxxName` to `TxxxName`, I think it’s time we retire these
implicit conversions, as they no longer save keystrokes, but continue
to present ambient danger associated with implicit conversions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| | |
Conflicts:
test/files/run/existentials-in-compiler.scala
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
After a discussion on a reflection meeting on Jul 17
we concluded that we should split staticModule into
staticModule and staticPackage to remove the ambiguity
between packageless objects and packageless packages
(more in the comments in the body of the commit).
The motivation is verbosely outlined in the comments,
but the bottom line is that Scala allows packages and
packageless objects to have the same name within the same program.
Therefore at times we need to disambiguate, hence the introduction
of the staticPackage method.
As of such staticModule no longer works for packages.
In the same fashion staticPackage doesn't work for modules.
This is done to ensure robustness of reification.
I would like to do the same for getModule in Definitions,
but we have to maintain backward compatibility. That's why I retained
the old behavior, but replaced getModule invocations with getPackage
where appropriate to be in line with staticModule and staticPackage.
Another important thing that follows from the discussion is that
both staticClass and staticModule prefer parent packages over parent objects
in cases of ambiguity. Say, if we have the following snippet of code:
object B { class C } next to package B { class C }
then staticClass("B.C") will never even consider a C inside the object B.
This is how scalac operates, so we decided to be consistent here.
Finally reification logic got changed to distinguish between
staticModule and staticPackage, and to allow for the fact that
staticClass and staticModule prefer parent packages to parent objects.
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
| |
It's more of a "dump what it says to a file so we'll know if
any of this ever changes" than a "test" per se. It could use
some wheat/chaff/nonsense/sense sorting. Still, it would
be great to have more stuff like this.
|
|
|
Direct compiler internals testing. It's really easy, you should probably
use it about 1000 times each. Look at the test:
run/existentials-in-compiler.scala
The checkfile contains the (string representations of the) actual
existentials from the compiler to make sure they correspond properly to
the ones in the source.
Existentials were being printed with wildcards too freely; this has been
tightened up.
|
