Inliner balances two competing goals: (a) aggressive inlining of: (a.1) the apply methods of anonymous closures, so that their anon-classes can be eliminated; (a.2) higher-order-methods defined in an external library, e.g.
Inliner balances two competing goals: (a) aggressive inlining of: (a.1) the apply methods of anonymous closures, so that their anon-classes can be eliminated; (a.2) higher-order-methods defined in an external library, e.g. Range.foreach() among many others. (b) circumventing the barrier to inter-library inlining that private accesses in the callee impose.
Summing up the discussion in SI-5442 and SI-5891, the current implementation achieves to a large degree both goals above, and overcomes a problem exhibited by previous versions:
(1) Problem: Attempting to access a private member p at runtime resulting in an IllegalAccessError, where p is defined in a library L, and is accessed from a library C (for Client), where C was compiled against L', an optimized version of L where the inliner made p public at the bytecode level. The only such members are fields, either synthetic or isParamAccessor, and thus having a dollar sign in their name (the accessibility of methods and constructors isn't touched by the inliner).
Thus we add one more goal to our list: (c) Compile C (either optimized or not) against any of L or L', so that it runs with either L or L' (in particular, compile against L' and run with L).
The chosen strategy is described in some detail in the comments for accessRequirements() and potentiallyPublicized(). Documentation at http://lamp.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/2011Q4/Inliner.pdf
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4