| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
The bug report suggests this problem only became visible in the
IDE *after* 2.10.3, but I tested an IDE with exactly 2.10.3 and
saw the same problem.
In fact, my test case fails as far back as 2.10.0. I suspect the
problem showed up after 816cecf9a9, which checks that pairs of
companion symbols are codefined eagerly in Namers.
This commit modifies the check of `rawInfo ne NoType`
in `isCoDefinedWith` to avoid triggering adaptation of types from
the previous run. I'm not sure of the precise intent of that check.
I looked at c9861cd198 (genesis of isCoDefinedWith). Before that we
get back to 3761cb4b3a1 (the dawn of Subversion.)
|
