Commit Graph

15 Commits

Author SHA1 Message Date
Tim Kientzle
1d961ba22d Add #include "swift/Basic/Assertions.h" to a lot of source files
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
2024-06-05 19:37:30 -07:00
Erik Eckstein
706f4c8622 Demangler library: add a function swift_demangle_getModuleName to get the module name of a mangled symbol.
rdar://problem/47560963
2019-02-19 11:26:42 -08:00
David Zarzycki
b61a34fe2b [SwiftDemangle] NFC: Increase portability via C standard APIs 2017-11-25 16:22:21 -05:00
Saleem Abdulrasool
7e888d43cd SwiftDemangle: build on non-Darwin targets
This can be useful as a consumer for demangling swift symbols.  Build
the shared library on non-Darwin targets as well.
2017-11-01 13:39:37 -07:00
Erik Eckstein
5e80555c9b demangler: put the demangler into a separate library
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
2017-03-09 13:42:43 -08:00
Erik Eckstein
be986d753c demangler: add an API to check if a function has the swiftcc calling convention 2017-03-01 14:16:38 -08:00
Erik Eckstein
b4c8f6bb15 Demangle: Don’t use demangle_wrappers in the SwiftDemangle library.
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
2017-02-16 09:59:21 -08:00
practicalswift
6d1ae2a39c [gardening] 2016 → 2017 2017-01-06 16:41:22 +01:00
Erik Eckstein
7208b18410 Mangling: support the new mangling prefix in various prefix checks 2016-12-15 14:08:11 -08:00
practicalswift
797b80765f [gardening] Use the correct base URL (https://swift.org) in references to the Swift website
Remove all references to the old non-TLS enabled base URL (http://swift.org)
2016-11-20 17:36:03 +01:00
Argyrios Kyrtzidis
404acacb21 [SwiftDemangle] Make an unexposed function static, NFC. 2016-02-16 12:16:56 -08:00
Zach Panzarino
e3a4147ac9 Update copyright date 2015-12-31 23:28:40 +00:00
David Farler
b460aa0c86 Further shorten demangled names in simplified mode
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
2015-07-16 03:35:46 +00:00
David Farler
4d71001aa4 Provide 'Simplified' demangling mode
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
2015-05-18 22:48:30 +00:00
Dmitri Hrybenko
321d4d4792 Rename libfunctionNameDemangle.dylib to libswiftDemangle.dylib
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
2015-04-03 22:12:28 +00:00