Where we have rethrowing versions of functions that have typed-throws
counterparts that are only retained for ABI compatibility, wrap them
in `#if !$Embedded` so they aren't compiled into the Embedded version
of the standard library. This eliminates warnings about this code,
which cannot actually be used with arbitrary errors anyway.
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.
This abbreviation for "if and only if" is confusing to those not coming
from a background in formal mathematics, and is frequently reported as a
type by developers reading the documentation.
This commit also changes doc comments in internal and private members,
which don't become part of the public documentation, because omitting
"iff" everywhere makes it much easier to check for any later changes
that reintroduce it.
In the corner case of a 0 sized replacement in an empty array, we did write the 0 count back to the array singleton.
This is not a big problem right now, because it would just overwrite a 0 with a 0, but it shouldn't be done.
But with COW representation in Array, it would break the sanity checks.
Add the `-warn-implicit-overrides` flag when building the standard library
and overlays, so that each protocol member that overrides a member of an
inherited protocol will produce a warning unless annotated with either
‘override’ or ‘@_nonoverride’.
An annotation of `override` will mean that the overriding requirement will be treated identically to the overridden declaration. If for some reason a concrete type’s conformance to the inheriting protocol provides a different witness for the overriding requirement than the conformance to the inherited protocol’s witness for the overridden requirement, the witness for the inheriting (more-specialized) protocol will be ignored. A protocol requirement marked ‘override’ only makes sense when the declaration is needed to help associated type inference, which is why the ‘override’ annotations correlate so closely with ABI FIXMEs.
An annotation of `@_nonoverride` means that the two protocol requirements will be treated independently, and may be bound to different witnesses. Use `@_nonoverride` when we might need different witnesses, e.g., because the semantics of the potentially-overriding declaration differ from that of the potentially-overridden declaration. `BidirectionalCollection.index(_:offsetBy:)` is the most obvious example, because the `BidirectionalCollection` ’s version of `index(_:offsetBy:)` allows negative indices. `RandomAccessCollection` ’s version is also marked `@_nonoverride` because it is required to be asymptotically faster than the `Collection` or `BidirectionalCollection` versions.
Aggressively remove all `@inlinable` from any function that's
`@inline(never)` to see the impact.
`@inlinable @inline(never)` is a potential code smell. While it might
expose some optimization and specialization opportunities to the
optimizer, it's most commonly a sign that more thought is needed.
* Remove Countable use from _ArrayBufferProtocol
* Mark _SwiftNativeNSArrayWithContiguousStorage's init @nonobjc
* Give {Closed}Range a _customIndexOfEquatableElement, supressing warning for _customContainsEquatableElement near-miss
* Eliminate CharacterView.init warning, since it's hard to supress and these things warn constantly.
* Move _copyBuffer to be an init on _ArrayBufferProtocol
* Make init(copying:) inlineable, even though its inline(never), to allow specialization.
* Delete old array swap test, as swap on arrays is no longer valid.
* Delete the old static method
* 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
* Give Sequence a top-level Element, constrain Iterator to match
* Remove many instances of Iterator.
* Fixed various hard-coded tests
* XFAIL a few tests that need further investigation
* Change assoc type for arrayLiteralConvertible
* Mop up remaining "better expressed as a where clause" warnings
* Fix UnicodeDecoders prototype test
* Fix UIntBuffer
* Fix hard-coded Element identifier in CSDiag
* Fix up more tests
* Account for flatMap changes
A recent change made accessibility checking stricter. This had some
fallout on the half-baked @_versioned attribute, where we could no
longer define @_versioned members on a non-@_versioned type.
This was wrong anyway (and will be diagnosed when we add proper
diagnostics for @_versioned), because type metadata for the
internal type did not get the right linkage, but it used to work
as long as you didn't try to get the type metadata at runtime.
This patch adds @_versioned attributes to the right types now that
this broken behavior is gone.
As a result, _Variant{Set,Dictionary}Storage became resilient
(non-@_versioned internal types are not resilient), which broke
too many tests that assumed you can exhaustively switch over all
the cases. Since eager-bridging is going to eliminate this enum
anyway (or so I've heard), make it @_fixed_layout for now.
* Migrate from `UnsafePointer<Void>` to `UnsafeRawPointer`.
As proposed in SE-0107: UnsafeRawPointer.
`void*` imports as `UnsafeMutableRawPointer`.
`const void*` imports as `UnsafeRawPointer`.
Occurrences of `UnsafePointer<Void>` are replaced with UnsafeRawPointer.
* Migrate overlays from UnsafePointer<Void> to UnsafeRawPointer.
This requires explicit memory binding in several places,
particularly in NSData and CoreAudio.
* Fix a bunch of test cases for Void->Raw migration.
* qsort takes IUO values
* Bridge `Unsafe[Mutable]RawPointer as `void [const] *`.
* Parse #dsohandle as UnsafeMutableRawPointer
* Update a bunch of test cases for Void->Raw migration.
* Trivial fix for the SceneKit test case.
* Add an UnsafeRawPointer self initializer.
This is unfortunately necessary for assignment between types imported from C.
* Tiny simplification of the initializer.
* Migrate from `UnsafePointer<Void>` to `UnsafeRawPointer`.
As proposed in SE-0107: UnsafeRawPointer.
`void*` imports as `UnsafeMutableRawPointer`.
`const void*` imports as `UnsafeRawPointer`.
Occurrences of `UnsafePointer<Void>` are replaced with UnsafeRawPointer.
* Migrate overlays from UnsafePointer<Void> to UnsafeRawPointer.
This requires explicit memory binding in several places,
particularly in NSData and CoreAudio.
* Fix a bunch of test cases for Void->Raw migration.
* qsort takes IUO values
* Bridge `Unsafe[Mutable]RawPointer as `void [const] *`.
* Parse #dsohandle as UnsafeMutableRawPointer
* Update a bunch of test cases for Void->Raw migration.
* Trivial fix for the SceneKit test case.
* Add an UnsafeRawPointer self initializer.
This is unfortunately necessary for assignment between types imported from C.
* Tiny simplification of the initializer.
This revises and expands on documentation for the new collection methods
for working with indices and the revised Swift 3 set APIs. In addition,
it includes documentation for the new range types.
