Dynamic expressions are represented as either operator expressions -
e.g., `d1 + d2`, `d[e]`, `d(e1, e2, e3)`, `d += e` -
where "operator" is a one of the known operators,
or as member reference expressions - e.g., `d.memberName` - where
member name is some arbitrary name (unresolved at compile-time and
represented as String).
Apparently function literals are translated without hiding the local declarations
in the wrapFunction call.
Which makes sense. Apart from the fact that it would also make
sense to do the same for private inline functions and function
literals inside other inline functions.
Local aliases can be copied as-is to a different fragment now. Before this change we would have had to extract the local alias tag (if any) from the source fragment and add to the destination fragment name bindings.
The tag generated during the source file translation could differ from
the tag generated based on the import statement (e.g. "intrinsic:..."
during generation becomes "'Kotlin'...." later on).
This means that the same function imported from the start and imported
during inlining has different tags. Which makes duplicate import removal
trickier. The best solution would be to make sure the tag generation
algorithms are consistent.
Current solution: rewrite the tags in terms of the Inliner tag
generation algorithm right after the source file translation.
Also it seems that some `var` statements we treated as imports, even
though they were not. Supported this behavior for now.
TODO: Get rid of these workaround
Module references were stored as plain JsName's. When inlining a function
from one fragment to another, those references should be re-interpreted
in terms of the destination fragment. Storing the whole module information
makes that much easier.
Dmitry Petrov