Commit Graph

11 Commits

Author SHA1 Message Date
Erik Eckstein
2d127e4192 Reinstate ”Use the new mangling for reflection."
It also uses the new mangling for type names in meta-data (except for top-level non-generic classes).
lldb has now support for new mangled metadata type names.

This reinstates commit 21ba292943.
2017-02-15 09:47:22 -08:00
Erik Eckstein
254f36aba5 Revert "Use the new mangling for reflection."
This needs some changes in lldb.
Disabled for now until lldb supports the new mangling.

This reverts commit 21ba292943.
2017-02-08 09:01:51 -08:00
Erik Eckstein
21ba292943 Use the new mangling for reflection.
For this we are linking the new re-mangler instead of the old one into the swift runtime library.
Also we are linking the new de-mangling into the swift runtime library.

It also switches to the new mangling for class names of generic swift classes in the metadata.
Note that for non-generic class we still have to use the old mangling, because the ObjC runtime in the OS depends on it (it de-mangles the class names).
But names of generic classes are not handled by the ObjC runtime anyway, so there should be no problem to change the mangling for those.
The reason for this change is that it avoids linking the old re-mangler into the runtime library.
2017-02-07 08:36:21 -08:00
Andrew Trick
1abeddcc5d [SILType] SILFunctionConventions API.
Separate formal lowered types from SIL types.
The SIL type of an argument will depend on the SIL module's conventions.
The module conventions are determined by the SIL stage and LangOpts.

Almost NFC, but specialized manglings are broken incidentally as a result of
fixes to the way passes handle book-keeping of aruments. The mangler is fixed in
the subsequent commit.

Otherwise, NFC is intended, but quite possible do to rewriting the logic in many
places.
2017-01-26 15:35:48 -08:00
Andrew Trick
b4f207313e [NFC] Specializationmangler ArgNo -> OrigArgIdx.
Names matter. When using an unsigned int to index arguments, always make it
clear what the index refers to. It is a particularly confusing in this code because:
- mangling should not care about argument indices at all, only the function type should matter.
- argument indices for a given function type may be different depending on the SIL stage.
- these indices are actually a contract between the client code and the mangler.
- the specialized function's argument indices are different than the original indices!

This issue was hiding bugs in the mangler. The bug fixes will be in a separate PR.
2017-01-26 15:35:48 -08:00
practicalswift
6d1ae2a39c [gardening] 2016 → 2017 2017-01-06 16:41:22 +01:00
Hugh Bellamy
ac3b56a554 Fix errors and warnings building swift/SILOptimizer on Windows using MSVC
-
https://connect.microsoft.com/VisualStudio/feedback/details/3116505/msvc-fails-to-compile-code-that-compiles-with-clang-reports-attempting-to-reference-a-deleted-function-error-from-destructor
-
https://connect.microsoft.com/VisualStudio/feedback/details/3116636/msvc-reports-ambiguous-symbol-error-for-friend-class-declaration-in-an-anonymous-namespace
2016-12-22 18:26:58 +00:00
Erik Eckstein
947996ceaf Mangling: encode an optional unique ID in the function specialization mangling, instead of appending _unique_suffix 2016-12-20 13:47:48 -08:00
Erik Eckstein
62e32a1044 Mangling: support for mangling of partial specializations 2016-12-13 11:03:21 -08:00
practicalswift
cfdaf9f14a [gardening] Fix invalid Swift URLs. 2016-12-06 20:12:20 +01:00
Erik Eckstein
684092d7d1 Mangling: mangler, demangler and remangler classes for the new mangling scheme.
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.
2016-12-02 15:55:30 -08:00