When a Swift struct gets bridged to Obj-C, we box it into an opaque
`_SwiftValue` Obj-C object. This object previously supported the
Obj-C `isEqual:` and `hash` selectors by dispatching to the Swift
Hashable conformance, if present.
This does not work if the Swift struct conforms to Equatable but
does not conform to Hashable. This case seems to have been
overlooked in PR #4124.
This PR extends the earlier work to support `isEqual:` by
first checking for a Hashable conformance, then falling back
on an Equatable conformance if there is no Hashable conformance.
Resolves rdar://114294889
This isn't a "complete" port of the standard library for embedded Swift, but
something that should serve as a starting point for further iterations on the
stdlib.
- General CMake logic for building a library as ".swiftmodule only" (ONLY_SWIFTMODULE).
- CMake logic in stdlib/public/core/CMakeLists.txt to start building the embedded stdlib for a handful of hardcoded target triples.
- Lots of annotations throughout the standard library to make types, functions, protocols unavailable in embedded Swift (@_unavailableInEmbedded).
- Mainly this is about stdlib functionality that relies on existentials, type erasure, metatypes, reflection, string interpolations.
- We rely on function body removal of unavailable functions to eliminate the actual problematic SIL code (existentials).
- Many .swift files are not included in the compilation of embedded stdlib at all, to simplify the scope of the annotations.
- EmbeddedStubs.swift is used to stub out (as unavailable and fatalError'd) the missing functionality.
* Removing FIXME from methods also marked always/never
* Unavailable/deprecated things don't need inlining
* Trivial implementations
* Enum namespaces
* Unsafe performance of opaque/raw pointer
* Dump doesn't need to be fast
* Error paths shouldn't require inlining
* Consistency with surrounding code
* Lazy performance needs specialization
- Clarify RawValue requirement for OptionSet
- Make Bool counterexample more clearly an error
- Add clarifying note about unsafe arithmetic methods
- Add/refine complexity docs for sequence/collection
- Remove docs from obsoleted symbols
- Standardize on unicode.org for links about Unicode
- More complexity annotations
- Expand dictionary defaulted subscript docs
- Fix error in Dictionary.init(minimumCapacity:) docs
- Improve accuracy of prime number listing
- Revise Equatable and Hashable for synthesized requirements
- Complete Strideable and stride(from:...:by:) documentation
- Revise DoubleWidth type docs
- Add complexity notes for Set.index(of:) and .contains(_:)
- Fix typos in Set.formUnion docs
- Add missing axioms for SetAlgebra (SR-6319)
- Improve guidance for description and debugDescription
- Add note about the result of passing duplicate keys to
Dictionary(uniqueKeysWithValues:)
- Fix typo in BinaryInteger docs
- Update Substring docs with better conversion example
- Improve docs for withMemoryRebound and isKnownUniquelyReferenced
- Add missing docs not propagated from protocols
At the Swift level, this is equivalent to AnyObject, which we've done
much more testing of. This commit paves the way for taking UnknownObject
out of the SIL type system and just using it as type metadata. Filed
https://bugs.swift.org/browse/SR-5926 to track that work.
Previously often times when casting a value, we would just pass along the
cleanup of the uncasted value. With semantic SIL this is no longer correct since
the cleanup now needs to be on the cast result.
This caused problems for certain usages of Builtin.castToNativeObject(...) by
the stdlib. Specifically, the stdlib was using this on AnyObject values that
were not necessarily native. Since we were recreating the cleanup on the native
value, a swift native release was being used =><=.
In this commit I solve this problem by:
1. Adding an assert in Builtin.castToNativeObject(...) that ensures that any value
passed to Builtin.castToNativeObject() is known conservatively to use swift
native reference counting.
2. I changed all uses where we do not have a precondition of a native ref
counting type to use Builtin.castToUnknownObject(...).
3. I added a new Builtin called Builtin.unsafeCastToNativeObject(...) that does
not have the compile time check. I used this to rewrite callsites in the stdlib
where we know via preconditions that an AnyObject will dynamically always be
native.
rdar://29791263
In various cases where we had global operators for non-generic
concrete types (such as String + String), move those operators into
the type. This should not affect the sources, but makes the exposition
of the library cleaner.
Plus, it's a good test for the compiler, which uncovered a few issues
where the compiler was coupled with the library.
Allow 'static' (or, in classes, final 'class') operators to be
declared within types and extensions thereof. Within protocols,
require operators to be marked 'static'. Use a warning with a Fix-It
to stage this in, so we don't break the world's code.
Protocol conformance checking already seems to work, so add some tests
for that. Update a pile of tests and the standard library to include
the required 'static' keywords.
There is an amusing name-mangling change here. Global operators were
getting marked as 'static' (for silly reasons), so their mangled names
had the 'Z' modifier for static methods, even though this doesn't make
sense. Now, operators within types and extensions need to be 'static'
as written.
