Previously it was part of swiftBasic.
The demangler library does not depend on llvm (except some header-only utilities like StringRef). Putting it into its own library makes sure that no llvm stuff will be linked into clients which use the demangler library.
This change also contains other refactoring, like moving demangler code into different files. This makes it easier to remove the old demangler from the runtime library when we switch to the new symbol mangling.
Also in this commit: remove some unused API functions from the demangler Context.
fixes rdar://problem/30503344
This avoids linking parts of the llvm utilities into the library.
It fixes an option-registere-more-than-once problem in the SwiftDemangle unit test.
rdar://problem/30503344
These changes caused a number of issues:
1. No debug info is emitted when a release-debug info compiler is built.
2. OS X deployment target specification is broken.
3. Swift options were broken without any attempt any recreating that
functionality. The specific option in question is --force-optimized-typechecker.
Such refactorings should be done in a fashion that does not break existing
users and use cases.
This reverts commit e6ce2ff388.
This reverts commit e8645f3750.
This reverts commit 89b038ea7e.
This reverts commit 497cac64d9.
This reverts commit 953ad094da.
This reverts commit e096d1c033.
rdar://30549345
This patch splits add_swift_library into two functions one which handles
the simple case of adding a library that is part of the compiler being
built and the second handling the more complicated case of "target"
libraries, which may need to build for one or more targets.
The new add_swift_library is built using llvm_add_library, which re-uses
LLVM's CMake modules. In adapting to use LLVM's modules some of
add_swift_library's named parameters have been removed and
LINK_LIBRARIES has changed to LINK_LIBS, and LLVM_LINK_COMPONENTS
changed to LINK_COMPONENTS.
This patch also cleans up libswiftBasic's handling of UUID library and
headers, and how it interfaces with gyb sources.
add_swift_library also no longer has the FILE_DEPENDS parameter, which
doesn't matter because llvm_add_library's DEPENDS parameter has the same
behavior.
'Ss' appears in manglings tens of thousands of times in the standard library and is also incredibly frequent in other modules. This alone is enough to shrink the standard library by 59KB.
Swift SVN r32409
Break up "Simplified" demangling mode (shortened demangled descriptions
for the sake of displaying in UI with small areas) into more
fine-grained options instead of an opaque "Simplified" option and
provide a static preset of options for displaying stack traces in
Xcode UI and other tools, for example.
- Don't print unmangled suffixes
- Don't print module names
- Shorten various generic specialization descriptions as just
"specialized"
- Don't display long protocol conformances
- Truncate where clauses
- Don't display so-called "entity" types
- Shorten "partial apply *"
- Shorten thunk phrases
- Shorten value witness phrases
- Truncate archetype references
rdar://problem/21753651
Swift SVN r30247
To support UI applications displaying demangled names in a limited
amount of screen space, provide a new SwiftDemangle API and Demangler
option to do the following:
- Skip all module name prefixes when printing contexts
- Don't print implicit self/metatype parameters when printing
function types
Add a '-simplified' flag to swift-demangle to support testing at the
command line.
Swift SVN r28727
This library becomes a permanent interface that we would need to support
in the long term, so we should get dylib names and APIs right.
rdar://20418214
Swift SVN r26957
