We deprecated overriding it in 4.2 with a custom compiler warning. This removes the ability to override it entirely.
The correct way to customize hashing for NSObject subclasses is to override the `hash` property.
When I added support for importing long double as Float80 on Intel, I neglected to conform it to CVarArgs. This patch fixes that, which most importantly lets users use String(format:) with Float80 values.
Completely mechanical changes:
- Explicit @objc in a few places
- Some imported APIs changed
- For the mix-and-match tests, just test version 4/5 instead of 3/4
Also move one from fast to slow based on the fact that it wasn't
representative of the original issue (which was an expression that
didn't typecheck successfully).
On older OSs, CLLocationCoordinate2D was an anonymous struct with a
typedef, which meant its Objective-C type encoding string was "{?=dd}"
instead of "{CLLocationCoordinate2D=dd}". This incompatibility led to
us rejecting casts from NSValues created with CLLocationCoordinate2Ds
in Objective-C on older OSs because they didn't match the type
encoding provided. Instead, we can try to create an NSValue the way
the frameworks do, and see what /its/ type encoding is. This is what
SceneKit already does.
There's an extra wrinkle here because the convenience methods for
encoding CLLocationCoordinate2Ds are actually added in MapKit rather
than CoreLocation. That means that if someone's app just uses
CoreLocation, we can't rely on those convenience methods to get the
correct type encoding. In this case, the best thing we can do is just
give up and use the static encoding.
This whole thing is indicative of a bigger problem, namely that
NSValue normally doesn't try to validate types at all. However, Swift
bridge casting really does want to distinguish, say, a
CLLocationCoordinate2D from a CGPoint, and checking the NSValue encode
string was a way to do that. But this shows that it's still not safe
to assume that's consistent against everything in a process even if
they're all using @encode on the real struct (or the Swift
equivalent), because the different parts of the process may have been
compiled against different SDKs.
This change does not attempt to solve that problem.
Finishes rdar://problem/44866579
The functions in LibcShims are used externally, some directly and some through @inlineable functions. These are changed to SWIFT_RUNTIME_STDLIB_SPI to better match their actual usage. Their names are also changed to add "_swift" to the front to match our naming conventions.
Three functions from SwiftObject.mm are changed to SPI and get a _swift prefix.
A few other support functions are also changed to SPI. They already had a prefix and look like they were meant to be SPI anyway. It was just hard to notice any mixup when they were #defined to the same thing.
rdar://problem/35863717
Keep the _NSKeyValueObservation in the runtime name, since we need to avoid colliding with the name used in the pre-ABI-stable libraries.
rdar://problem/44914709
Apparently this changed at some point in the past (it used to just be
"$"). The actual value isn't so important, so just skip that part.
Part of rdar://problem/44866579
remote-run doesn't always preserve the interleaving, but we don't need
stdout at all given what's being checked; it's just used to show how
far the test got before failing. The output being FileChecked is going
through NSLog, which uses stderr.
Part of rdar://problem/44866579
When mapping from type metadata to a demangle tree, fill in the complete
set of generic arguments. Most of the effort here is in dealing with
extensions that involve same-type constraints on a generic parameter, e.g.,
extension Array where String == Element { }
extension Dictionary where Key == Value { }
In such cases, the metadata won’t contain generic arguments for every
generic parameter. Rather, the generic arguments for non-key generic
parameters will need to be computed based on the same-type requirements
of the context. Do so, and eliminate the old hacks that put the generic
arguments on the innermost type. We don’t need them any more.
Part of rdar://problem/37170296.
This makes diagnostics more verbose and accurate, because
it's possible to distinguish how many parameters there are
based on the message itself.
Also there are multiple diagnostic messages in a format of
`<descriptive-kind> <decl-name> ...` that get printed as
e.g. `subscript 'subscript'` if empty labels are omitted.
Reimplement SubstGenericParametersFromMetadata to cope with non-key
generic parameters, which are counted when referring to generic parameters
from metadata but do not have corresponding generic arguments.
The use of `__APPLE__` is unnecessary as the case is guarded by the
`SWIFT_DARWIN_ENABLE_STABLE_ABI_BIT` preprocessor guard which is implicitly
specific to that environment. Additionally, flip the condition around so that
the positive (which is the future) appears ahead of the negative case.
`\.self` is the final chosen syntax. Implement support for this syntax, and remove the stopgap builtin and `WritableKeyPath._identity` property that were in place before.
In order to provide source compatibility with existing user types conforming to BinaryInteger, we want to have a default implementation available. It's somewhat difficult to provide a good default implementation that correctly handles arbitrary non-symmetrical ranges in the face of negative divisors, so fall back on testing divisibility of the magnitudes, which avoids the problem.
On the plus side, this default implementation works fine for types conforming to UnsignedInteger, which lets us move the FixedWidthInteger implementation down to FixedWidthInteger & SignedInteger, and simplify it in the process.
* Implement SE-0225 (BinaryInteger.isMultiple(of:))
A default implementation is provided for FixedWidthInteger, with very basic test coverage included.
This should have been done for Swift 4.2 according to SE-0204, but
better later than never. Deprecating these methods as of Swift 5.0.
Also modfying the tests to check for the deprecation message.
Fixes: <rdar://problem/43694210>
