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.
- Reduce the emphasis on the type theory that Never is an uninhabited
type, focusing more on its meaning and usage in code.
- Move the definition of uninhabited out of the abstract. Define
"nonreturning" more explicitly.
- Expand the favoriteNumber example's code comment into a brief
paragraph to walk through the code listing.
- Avoid italics in the abstract, future tense, and parenthetical asides.
- Use contractions.
Before this change, the ABI checker didn't complain about missing @available
attributes on new APIs if the enclosing scopes of new APIs have
availability information. Instead, we should require explicit @available attributes
for new APIs to prevent them inheriting wrong availability information from a
preexisting scope.
rdar://81719628
Designated types were removed from the constraint solver in #34315, but they are currently still represented in the AST and fully checked. This change removes them as completely as possible without breaking source compatibility (mainly with old swiftinterfaces) or changing the SwiftSyntax tree. Designated types are still parsed, but they are dropped immediately and a warning is diagnosed. During decl checking we also still check if the precedence group is really a designated type, but only so that we can diagnose a warning and fall back to DefaultPrecedence.
This change also fixes an apparent bug in the parser where we did not diagnose operator declarations that contained a `:` followed by a non-identifier token.
Introduce checking of ConcurrentValue conformances:
- For structs, check that each stored property conforms to ConcurrentValue
- For enums, check that each associated value conforms to ConcurrentValue
- For classes, check that each stored property is immutable and conforms
to ConcurrentValue
Because all of the stored properties / associated values need to be
visible for this check to work, limit ConcurrentValue conformances to
be in the same source file as the type definition.
This checking can be disabled by conforming to a new marker protocol,
UnsafeConcurrentValue, that refines ConcurrentValue.
UnsafeConcurrentValue otherwise his no specific meaning. This allows
both "I know what I'm doing" for types that manage concurrent access
themselves as well as enabling retroactive conformance, both of which
are fundamentally unsafe but also quite necessary.
The bulk of this change ended up being to the standard library, because
all conformances of standard library types to the ConcurrentValue
protocol needed to be sunk down into the standard library so they
would benefit from the checking above. There were numerous little
mistakes in the initial pass through the stsandard library types that
have now been corrected.
Correct the maximal floating point width. Although technically, Android
could support FP128 on AArch64, Swift does not currently support FP128.
For now, ensure that we use FP64 on Android.
PR #20528 was merged yesterday, which inserts an `unreachable` in
functions with uninhabited parameters. Unfortunately this means any
statement in the function body, even ones that themselves are
never-returning or don't have any executable code, cause the warning.
Silence the warnings by deleting the bodies of these functions.
Also add overloads for these operators to an extension of Array.
This allows us to typecheck array concatenation quickly with
designated type support enabled and the remaining type checker hacks
disabled.
Have the constraint solver consider multiple designated types for an
operator. We currently consider the overloads from each in turn,
stopping as soon as we have a solution. As a result, we can still end
up with exponential type checking in some cases if an operator has
more than a single designated type. This still allows us to reduce the
base of that exponent, though, which makes it possible to increase the
number of expressions we can type check successfully in practice.
Also enable the parsing of these with
-enable-operator-designated-protocols in the stdlib build.
The constraint solver support to make use of these is not yet in-tree.
and will probably land with a different command-line option to enable
it, so that we can continue to have parsing support enabled in-tree
while the constraint solver support is iteratively improved.
The removal of these operator declarations caused a source
compatibility break, because some Swift code is defining prefix or
postfix ++/-- functions without defining the ++ or --
operators. Reinstate the operator declarations in the standard
library... but not any of the functions.
Fixes rdar://problem/43258773.
We still had unavailable versions of these for floating-point types
only. We shouldn't need to keep these around, and can instead just
emit a helpful diagnostic for anyone that attempts to use them.
Unfortunately I don't see any way for the diagnostic to produce an
actual fix-it, so it just suggests '+= 1' or '-= 1' without actually
producing a fix.
- 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
In theory there could be a "fixed-layout" enum that's not exhaustive
but promises not to add any more cases with payloads, but we don't
need that distinction today.
(Note that @objc enums are still "fixed-layout" in the actual sense of
"having a compile-time known layout". There's just no special way to
spell that.)
Fixes: https://bugs.swift.org/browse/SR-7019
Prior to Swift 4 and the new integers, there was a protocol called
`BitwiseOperations`. It was deemed not needed with the introduction of
the integer protocols. But, for backward compatibility, it was left in
the standard library as `_BitwiseOperations` with a conditionally
available typealias `BitwiseOperations`. That protocol declares only the
"non-muating" operators, the mutating ones (i.e. `|=` and friends) are
defined as free functions. They are implemented in terms of
`_BitwiseOperations` protocol requirements, which is reasonable.
In the new integer protocols we established a
convention to provide default implementations for non-mutating functions
in terms of mutating ones (exactly the opposite of a much earlier
decision made for `BitwiseOperations`). So now, when you define a type
that conforms to the `FixedWidthInteger`, even though both mutating and
non-mutating bitwise operations are required, the default implementation
of `|` comes from extension FixedWidthInteger, and the default
implementation of `|=` comes from the _BitwiseOperations free functions.
And they are mutually recursive. Hence the crash.
This commit breaks the recursion by marking default implementations for
`|` etc. in `_BitwiseOperations` obsoleted from Swift 4.1 onward. The
test is also added to make sure the change helps.
Cygwin is considered a distinct target with a distinct ABI, environment
conditions, and data types. Though the goal of the project is
native Windows integration with UNIX-likes, that is not compatible with
the idea that the platform can be ignored as Win-like enough to have the
existing os(Windows) condition apply.
