Rather than waiting until we've used a huge amount of memory, attempt to
make the choice to bail out based on the number of type bindings /
disjunction choices we visit.
I expect this will generally fail faster than the Swift 3 metric, but
will still only fail when we've got clearly exponential type checking
behvior.
Since we have multiple sources of exponential behavior today, I don't
want to make the bounds too tight. Once we fix some/most of that
behavior we can look at further tightening up the metric.
The difference is that TransformArrayRef stores its function as an std::function
instead of using a template parameter. This is useful in situations where one
wants to define such a type in a header on forward declared pointers. If one had
to define the function to be used as a template parameter, one would have to
define the function or provide a forward declared version
Use a new mangling scheme that describes the layout of compound boxes. For compatibility with reflection-based clients, continue to use the legacy mangling for single-field boxes when emitting reflection TypeRefs until we fully support reflection for the new box implementation.
This will allow for modules to be split from the command line using a script.
The one thing that is missing from this still is that it does not handle shared
functions in IMO a satisfactory way. Given that we are splitting a module, my
feeling that the correct way to do this is to create a public shim for the
shared function in the module that the shared function gets put in and let all
other users use that entry point.
But I need to think about this a bit more.
Groups are required for Timers after SVN r286524. SVN r287369 requires that
timers have short names and long descriptions. Adjust the API usage
accordingly. Reorder some words to make some more sense as a description.
Following classes provide symbol mangling for specific purposes:
*) Mangler: the base mangler class, just providing some basic utilities
*) ASTMangler: for mangling AST declarations
*) SpecializationMangler: to be used in the optimizer for mangling specialized function names
*) IRGenMangler: mangling all kind of symbols in IRGen
All those classes are not used yet, so it’s basically a NFC.
Another change is that some demangler node types are added (either because they were missing or the new demangler needs them).
Those new nodes also need to be handled in the old demangler, but this should also be a NFC as those nodes are not created by the old demangler.
My plan is to keep the old and new mangling implementation in parallel for some time. After that we can remove the old mangler.
Currently the new implementation is scoped in the NewMangling namespace. This namespace should be renamed after the old mangler is removed.
