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.
* One-sided ranges and RangeExpression
* Remove redundant ClosedRange methods from String
* Fix up brittle tests
* Account for Substring update
* XFAIL range diagnostics on Linux
- CYGWIN symbol is used to distinguish Cygwin environment from other OS
and other environment in Windows.
- Added windows and windowsCygnus to OSVersion in StdlibUnittest
Precedence of '->' was too low.
`_ = () -> Int` was folded as:
(arrow
(assign
(discard_assignment_expr)
(tuple_expr))
(unresolved_declref))
It should be:
(assign
(discard_assignment_expr)
(arrow
(tuple_expr)
(unresolved_declref)))
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
Mostly NFC, this is just plumbing for the next patch.
Note that isNever() returns true for any uninhabited
enum.
It should be generalized so that stuff like (Never, Int)
is also known to be uninhabited, or even to support
generic substitutions that yield uninhabited types,
but for now I really see no reason to go that far, and
the current check for an enum with no cases seems
perfectly adequate.
Also adds:
- Any is caught before doing an unconstrained lookup, and the
protocol<> type is emitted
- composition expressions can be handled by
`PreCheckExpression::simplifyTypeExpr` to so you can do lookups like (P
& Q).self
- Fixits corrected & new tests added
- Typeref lowering cases should have been optional
- This fixes a failing test case.
