@differentiable function is actually a triple (function, jvp, vjp). Previously normal thick function value witness table was used. As a result, for example, only function was copied, but none of differential components.
This was the cause of uninitialized memory accesses and subsequent segfaults.
Should fix now unavailable TF-1122
Fixes a couple of compiler warnings that occur frequently when building the compiler:
- Copy the nullability annotation definitions from `Visibility.h` to `BridgedSwiftObject.h` and wrap all code that contains nullability annotations in `SWIFT_BEGIN_NULLABILITY_ANNOTATIONS` and `SWIFT_END_NULLABILITY_ANNOTATIONS` (supressing the warning `type nullability specifier '_Nullable' is a Clang extension [-Wnullability-extension]`)
- Suppress warnings about using `$` (mangling prefix) as an identifier using pragmas (supressing the warning `'$' in identifier [-Wdollar-in-identifier-extension]`)
- Change the macro condition of `SWIFT_NODISCARD` from `__cplusplus >= 201402l` (which checked for >= C++14) to `__cplusplus > 201402l`. This appears to have been a copy-paste error from `LLVM_NODISCARD` (supressing the warning `use of the 'nodiscard' attribute is a C++17 extension [-Wc++17-extensions]`)
The prefab'ed value witness tables for reference storage types are a
premature optimization. Not all scenarios are covered, and those that
are "look suspect" according to John McCall.
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
