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.
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.
Previously we had two separate mechanisms to turn a metatype
into a string. The swift_typeName() function was used to print
the metatype in a human-readable fashion, whereas the
_swift_buildDemanglingForMetadata() was used when naming
generated generic Objective-C classes.
Unify them, since what swift_typeName() does is redundant;
instead of going directly from the metatype to a human-readable
string, we can get the mangling, and print that using the
demangler.
This fixes some issues with unnecessary parenthesis when
printing function types, and also allows Objective-C classes
to be instantiated with nested generic types as parameters.
When in Swift 3 Compatibility Mode we now acceptable a standalone
'$' as an identifier. In all other cases this is now disallowed
and must be surrounded by backticks.
We don't want the machine calling conventions for closure invocation functions to necessarily be tied to the convention for normal thin functions or methods. NFC yet; for now, 'closure' follows the same behavior as the 'method' convention, but as part of partial_apply simplification it will be a requirement that partial_apply takes a @convention(closure) function and a box and produces a @convention(thick) function from them.
llvm r283043 and possibly other recent changes switch to use StringRef
instead of char* pointers. Update Swift to match. In some cases, this is
a clear improvement. It would be good to assess the impact on memory use,
particularly for the Filename component of source locations.
Note that the change to SILLocation::isNull fixes an apparent bug where
the location was treated as null when the filename was *not* null.
The recent @escaping on variadic argument closures back-compat fix is
the first Swift 3.0 compatibility behavior that we don't want to carry
forwards indefinitely into the future. To address this, we
version-gate the diagnostic suppression.
Makes it an official compatibility check. Creates new test directory
for compatibility testing. Allow -swift-version 4 so that we can test
it both ways.
With a bit of work, we can re-purpose the existing
QualifiedArchetype mangling to cover this case.
This allows us to get rid of a usage of
ArchetypeType::getSelfProtocol(), which we want to remove.
This flag switches the "effective language version" of the compiler,
at least to any version supported (as of this change: "3" or "3.0").
At the moment nothing uses it except the language version build
configuration statements (#if swift(...)) and various other places
that report, encode, or otherwise check version numbers.
In the future, it's intended as scaffolding for backwards compatibility.
Fixes SR-2582
Now that I am going to be adding an IN_SWIFT_COMPONENT argument, I need to do
this to distinguish the concepts of an LLVM_COMPONENT and a SWIFT_COMPONENT.
