You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The inliner duplicates trees and their symbols when expanding inline
definitions at call sites. When the RHS of the inline definition
contains a class definition its Symbol is duplicated, I believe
correctly, preserving the original position and associated source file.
The tree is duplicated, I believe also correctly, with its source
attribute reflecting that the tree has been expanded in the call site
source file.
In most circumstances the potential mismatch between the souce of the
Symbol and the source of its defining tree is handled: in Symbol#source
the source of the defining tree will be used prior to erasure if the
tree is non-empty, which ensures that the source as viewed via the
Symbol will be the same as the source as viewed via the tree.
Things can go awry after erasure, however. In ExpandPrivate there is a
same-source-file test relaxing access controls to private members of
module classes. Because this happens after erasure it's possible that if
a class definition has been inlined into a module and members attempt to
access a definition in the module (eg. something synthetic which has
been lifted into the module) the same-source-file test will fail because
the source of the class symbol will now be seen as the source of the
inline definition rather than the source of the inlined call site.
This is the scenario exercised in the included test. The inlined
refinement and by-name argument are both essential (the latter is
responsible for the private synthetic term which is lifted out into the
module and then incorrectly reported as inaccessible from the inlined
body).
In the real code from which this was reduced the refinement was actually
the expansion of a polymorphic function type, but as the test shows
there's nothing specific to polymorphic function types here.
The simplest approach to fixing this appears to be in ExpandPrivate
where if the accessing symbol (on the context.owner side) doesn't have
a matching source file we fall back to checking against the source file
of the current compilation unit.
0 commit comments