dart-archive
Need renamer for module exports introduced by the compiler
We currently handle all renames of temporaries inside a module. But those are all local variables, and private outside of the module. We also have cases where the compiler introduces an export from the module (where ES6 module corresponds 1:1 to a Dart library). Those are different kind of thing. For those, we need to be able to compute the name without access to the original source code, only the Elements. So the naming choice must only depend on data we have available in the element model.
(Note: also good to minimize cases we introduce public names. We currently do it for generic types, and for extension method symbols.)
CC @leafpetersen who was chatting about this yesterday with
Current examples of introduced names: List$ for List<E> and $add for the extension method List.add
Also, these should probably use a different naming convention from temps.
One obvious way to do this is to reserve some seldom used (or even illegal) pattern for ddc use, and mangle any user defined identifiers that collide. So, e.g., we could say that all generated identifiers that end with exactly one dollar sign ($) are ddc identifiers, and mangle any user generated identifiers ending in one or more dollar signs by doubling each $. So List$ is a ddc identifier, and if the user writes List$ we generate List$$. We can probably come up with less intrusive variants of this.
Another approach might be to try to use namespacing. We could reserve a single sub-namespace (e.g. ddc), and then place all of the extra global names in that namespace. So if we want to add List$ to the collections library, we put it in collections.ddc.List$, and then maybe bind it to a local short name using the existing temporary mechanism. In most cases we could hopefully use temporaries to bind to a local name at the top of the file. We still have to deal with the case that the user collides with our reserved namespace name, but by restricting it to one name we make this easier to avoid. Alternatively, we could probably use a symbol for the namespace, though this just pushes the problem back to how we manage collisions with the "dart.foo" namespace.
note: extension methods were fixed (moved to a different namespace) so only the generic type vs dynamic instance is left.
One obvious way to do this is to reserve some seldom used (or even illegal) pattern for ddc use, and mangle any user defined identifiers that collide
+1, I think that's probably easiest to integrate with separate compilation