I found the same and had a pull request cooked but I had no internet access to push.
On library, reflect and compiler the number of warning is reduced by 50%. Lots of remaining ones are related to Predef.->. I'll follow up with a ticket.
--
Sent from my Android
Grzegorz
I patched the Inliner to prevent it from making any fields public, and noticed several anon-closures not being inlined anymore as hinted by:
instruction LOAD_FIELD value $outer requires private access.
The current version of canMakePublic() makes public outer fields, as well as others. It can be made more restrictive.
The alternative, regarding all apply methods of anon-closures as @inline annotated, would have to deal with outer fields being introduced after SuperAccessors has run.
def canMakePublic(f: Symbol): Boolean =
(m.sourceFile ne NoSourceFile) &&
(f.isSynthetic || f.isParamAccessor) &&
{ toBecomePublic = f :: toBecomePublic; true }
Miguel
http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/
On Thursday, August 9, 2012 8:11:18 PM UTC+2, martin wrote:So, I made the changes to the inliner that all fields and methods accessed by an @inline method are made not private. But the inliner still did not work for them, when compiled separately. I could trace the reason to the (now obsolete) "potentially publized" logic, which will refuse to inline any separately compiled reference that has a $ in it. I submitted a pull request that disregards "potentiallyPublicized" when checking fields for inlineability.I verified that the change reduces the number of "cannot inline" warnings for Typers.scala from ~250 to 19.But I could not do a complete reversal of the publication logic to make the change safe. Vlad or Miguel, can you have a look at this? In particular, I think the inliner should no longer make private fields public.Thanks!- Martin--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967
(In order to synchronize with Greg, some implementation details)
Following that approach, the change in the inliner amounts to:(m.sourceFile ne NoSourceFile) && (m.sourceFile ne null) && // "compiled in this run" ie not grabbed from external library
def canMakePublic(f: Symbol): Boolean =
hasInline(f.owner) &&ie only those private fields of a class being compiled that are accessed in @inline-marked methods are publicized.
{ toBecomePublic = f :: toBecomePublic; true }
Just to recap, ExplicitOuter should have taken care of publicizing all other fields required for inlining (e.g., outer fields of anon-closure-classes)
(In order to synchronize with Greg, some implementation details)
Following that approach, the change in the inliner amounts to:(m.sourceFile ne NoSourceFile) && (m.sourceFile ne null) && // "compiled in this run" ie not grabbed from external library
def canMakePublic(f: Symbol): Boolean =
hasInline(f.owner) &&ie only those private fields of a class being compiled that are accessed in @inline-marked methods are publicized.
{ toBecomePublic = f :: toBecomePublic; true }
Just to recap, ExplicitOuter should have taken care of publicizing all other fields required for inlining (e.g., outer fields of anon-closure-classes)
--
Grzegorz Kossakowski
Because of separate compilation: The inliner looks at the Scala types, not at the Java types. That's potentially a mistake, it might have been more robust to look at the Java types. But that's how inliner works now.Now, looking at the Scala types, the inliner sees what got pickled subject to any symbol info transforms afterwards. Crucially, the symbol info transforms will never look at internal code of separately compiled classes. So if ExplicitOuter for a separately compiled class decides that a field should be public, that info cannot be propagated to separately compiled clients.But as long as both classes agree on the "meta-knowledge" that all fields accessed by @inline will be made public they can still work OK together. It's just that clients will have to manually duplicate the access widening transform that they know the server will have performed.