Conforming types already provide the static bitWidth property. Instance
one can be implemented in a protocol extension.
Resolves: <rdar://problem/30186638>
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.
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.
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.
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.
Remove 16 concrete init(stringInterpolationSegment:) overloads and
replace them with 3 generic overloads, significantly reducing the
exponential blow-up from larger string interpolations.
Fixes rdar://problem/29389887.
The old method of constructing a mangled class name does not work anymore with the new mangling scheme.
Also, by using the re-mangler, _typeByName now works with class names containing non-ascii characters.
These were overlooked, and somehow code that attempted to make a minimal collection conform to RangeReplaceableCollection and RandomAccessCollection managed to compile successfully in Swift 3.0, but in Swift 3.1…*something* changed to reject a type that conforms to both due to the lack of a suitable default slicing subscript implementation in the stdlib that provided all the requirements. Fill in these missing implementations, fixing rdar://problem/30228957.
Remove 16 concrete init(stringInterpolationSegment:) overloads and
replace them with 3 generic overloads, significantly reducing the
exponential blow-up from larger string interpolations.
Fixes rdar://problem/29389887.
