These protocols were introduced to work around the problem where
compiler could not correctly handle instance of multiple @available
attributes (one for the language version and another for teh OS version)
applied to the same member.
Now that the compiler issues has been fixed, it is the right time to get
rid of the workarounds.
Addresses: <rdar://problem/36556261>
Now that Array and Dictionary conform to Hashable, we need to make sure that their bridged counterparts provide the same hash values when converted to AnyHashable.
* Make the underlying builtins for FP + Vector match Integer.
For stdlib integer types, these are named `_value` and `init(_ _value: Builtin.xxx)`. This patch adopts the same scheme for stdlib floating point and SDK overlay vector types, and removes a legacy init for integers that was only needed to support them. There should be no changes visible outside of the stdlib, and no functional change within the stdlib; the naming of some implementation details is simply more uniform now.
* Updates to tgmath functions for CGFloat
These changes bring CGFloat in line with the other FloatingPoint types. Some of this stuff is now defined at the protocol level, so we can get rid of it at the concrete type level. A couple other functions have been deprecated for all types, with protocol or tgmath replacements.
This allows them to be used in generic arguments for NSArray et al.
We already do this for the ones that wrap bridged values (like
NSString/String), but failed to do it for objects that /weren't/
bridged to Swift values (class instances and protocol compositions),
or for Error-which-is-special.
In addition to this being a sensible thing to do, /not/ doing this led
to IRGen getting very confused (i.e. crashing) when we imported a
Objective-C protocol that actually used an NS_TYPED_ENUM in this way.
(We actually shouldn't be using Swift's IRGen logic to emit protocol
descriptors for imported protocols at all, because it's possible we
weren't able to import all the requirements. But that's a separate
issue.)
https://bugs.swift.org/browse/SR-6844
It looks like we exposed a bunch of Metal APIs to Swift 3 that we
didn't mean to; at this point it would be a source-breaking change to
hide them. Oops.
- When a count was part of the format string, we looked at the
wrong character when forming the count.
- The OSLF_CMD_TYPE_DATA command type expects a pointer preceded
by a OSLF_CMD_TYPE_COUNT command, not 'count' bytes inline.
Fixes <rdar://problem/38080623>.
Despite their similar names and uses, these protocols no longer share
much functionality - the former is used to take @objc enums defined in
Swift that conform to Error and expose them as NSErrors, and the
latter handles NS_ERROR_ENUM C enums, which get imported into Swift as
a wrapper around NSError. We can actually simplify them quite a bit.
- Eliminate base protocol __BridgedNSError, which no longer provides
any implementation for _BridgedStoredNSError.
- Eliminate default implementations that match what the compiler would
synthesize.
- Adopt recursive constraints and where-clauses on associated types
(and update the Clang importer to handle this).
- Collapse signed and unsigned default implementations when reasonable.
- Fold _BridgedStoredNSError's _nsErrorDomain into the existing public
requirement CustomNSError.errorDomain.
rdar://problem/35230080
This can eventually be made more efficient by avoiding copies in all the
callees, but this is the minimal fix. Remove an unnecessary bit of
reverse-dependency on the Foundation overlay while we're here.
rdar://34222540
Deprecated the `PlaygroundQuickLook` enum and `CustomPlaygroundQuickLookable`
protocol. These are being targeted for removal in Swift 5, so we want to
unconditionally deprecate them now to encourage use of
`CustomPlaygroundDisplayConvertible` instead.
This commit includes deprecated the various `CustomPlaygroundQuickLookable`
conformances across the standard library and overlay libraries.
* Make Range conditionally a Collection
* Convert ClosedRange to conditionally a collection
* De-gyb Range/ClosedRange, refactoring some methods.
* Remove use of Countable{Closed}Range from stdlib
* Remove Countable use from Foundation
* Fix test errors and warnings resulting from Range/CountableRange collapse
* fix prespecialize test for new mangling
* Update CoreAudio use of CountableRange
* Update SwiftSyntax use of CountableRange
* Restore ClosedRange.Index: Hashable conformance
* Move fixed typechecker slowness test for array-of-ranges from slow to fast, yay
* Apply Doug's patch to loosen test to just check for error
This new format more efficiently represents existing information, while
more accurately encoding important information about nested generic
contexts with same-type and layout constraints that need to be evaluated
at runtime. It's also designed with an eye to forward- and
backward-compatible expansion for ABI stability with future Swift
versions.
clang is miscompiling some swiftcall functions on armv7s.
Stop using swiftcall in some places until it is fixed.
Reverts c5bf2ec (#13299).
rdar://35973477
NSString has a stricter concept of equality than Swift’s String, so it is possible to construct NSDictionary/NSSet instances that contain duplicate keys according to Swift’s definition of string equality. This change improves how we handle these cases by coalescing the duplicate keys (keeping a single value).
rdar://problem/35995647
* Remove a bunch of Default(Bidirectional|RandomAccess)Indices usage from stdlib and test
* Remove some DefaultRandomAccessIndices and IndexDistance usage from Foundation
* Remove no-longer-used internal type in Existentials.swift
* Get rid of indicesForTraversal
Inserting and removing a single Unicode.Scalar in a CharacterSet must not
attempt to create a Range<Unicode.Scalar> because the upperBound value might
not always be a valid UnicodeScalar.
This fixes a regression to the fix for SR-2988.
