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
The ABI mismatch here would cause a crash in cases when the Foundation overlay wasn't available, or its implementation of swift_Foundation_getErrorDefaultUserInfo wasn't dynamically resolvable, such as in a stripped statically linked binary. Fixes rdar://problem/29173132.
The lazy population of the NSError fields is ordered such that the domain is written into the object last with acq/rel ordering, so another thread only needs to check the domain to see whether the initialization has already happened. (The initialization itself is idempotent, so we can optimistically perform the initialization and discard the results if we race.) Checking the user info is redundant, and is also wrong for real NSError objects, since [NSError errorWithDomain:d code:c userInfo:nil] will in fact plant nil in the userInfo field of the object, leading us to attempt to bridge an already-native NSError.
Due to implicit promotion to optional it is possible to call flatMap
with a closure, that does not return an optional. This way the code
works, but is unnecessary inefficient. Such uses of flatMap can and
should be replaced with map.
This avoids indirection by making calls directly to the C implementations which prevents potentials of mismatched intent or changes of calling convention of @_silgen. The added benefit is that all of the shims in this case are no longer visible symbols (anyone using them was not authorized out side of the Foundation overlay). Also the callout methods in the headers now all share similar naming shcemes for easier refactoring and searching in the style of __NS<class><action> style. The previous compiled C/Objective-C source files were built with MRR the new headers MUST be ARC by Swift import rules.
The one caveat is that certain functions MUST avoid the bridge case (since they are part of the bridging code-paths and that would incur a recursive potential) which have the types erased up to NSObject * via the macro NS_NON_BRIDGED.
The remaining @_silgen declarations are either swift functions exposed externally to the rest of Swift’s runtime or are included in NSNumber.gyb which the Foundation team has other plans for removing those @_silgen functions at a later date and Data.swift has one external function left with @_silgen which is blocked by a bug in the compiler which seems to improperly import that particular method as an inline c function.
FloatingPoint should imply Hashable.
`Hashable` is related to `Equatable`, and `FloatingPoint` is `Equatable`, with enough additional constraints that `Hashable` conformance is practical.
There's *almost* no excuse for any `Equatable` thing not to also be `Hashable`; the exception is when the underlying representation may be denormalized in some way that makes it impossible or expensive to normalize (e.g. `Set`). Floating point numbers have denormalized forms, so this comes down to the cost of normalization. Since we can't imagine a representation whose normalization is much more expensive than the subsequent hashing step, the conformance belongs.
