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.
This commit defines the ‘Any’ keyword, implements parsing for composing
types with an infix ‘&’, and provides a fixit to convert ‘protocol<>’
- Updated tests & stdlib for new composition syntax
- Provide errors when compositions used in inheritance.
Any is treated as a contextual keyword. The name ‘Any’
is used emit the empty composition type. We have to
stop user declaring top level types spelled ‘Any’ too.
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.
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
This documentation revision covers a large number of types & protocols:
String, its views and their indices, the Unicode codec types and protocol,
as well as Character, UnicodeScalar, and StaticString, among others.
This also includes a few small changes across the standard library for
consistency.
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.
Adding a note to the doc comment on Comparable protocol, saying that it
only defines strict total order on normal (non-exceptional) values of
conforming types.
