Adds support for printing a C++ foreign reference in Swift.
Also skips metadata of private fields in C++ records imported as Swift classes, following up on #81035
(cherry-picked from 848fad0021)
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.
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.
LLDB tests rely on being able to print this thing, but LLDB itself
doesn't handle resilient types correctly yet. Sidestep the issue
while we work on a better fix in rdar://problem/38719739.
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.)
Since these are now deprecated (in preparation for removal in a future Swift
release), the doc comments reflect that and provide suggestions for what to do
instead (i.e. use `CustomPlaygroundDisplayConvertible`) and how to
conditionalize usage of `PlaygroundQuickLook`/`CustomPlaygroundQuickLookable` so
that source code remains compilable both by old versions which only have the old
protocol and newer versions which have removed the old protocol.
Deprecated the `PlaygroundQuickLook` enum and `CustomPlaygroundQuickLookable`
protocol. These are being targeted for removal in Swift 5, so we want to
unconditionally deprecate them now to encourage use of
`CustomPlaygroundDisplayConvertible` instead.
This commit includes deprecated the various `CustomPlaygroundQuickLookable`
conformances across the standard library and overlay libraries.
The old-style mirrors were the basis for non-custom, reflection based Mirrors. As part of removing old-style mirrors, reflection based Mirrors are reimplemented without them. Reflection.mm is deleted and replaced with ReflectionMirror.mm, which borrows a chunk of the old code but presents a simpler API to the Swift side. ReflectionMirror.swift then uses that API to implement a reflection-based Mirror init.
rdar://problem/20356017
* 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
* Eradicate IndexDistance associated type, replacing with Int everywhere
* Consistently use Int for ExistentialCollection’s IndexDistance type.
* Fix test for IndexDistance removal
* Remove a handful of no-longer-needed explicit types
* Add compatibility shims for non-Int index distances
* Test compatibility shim
* Move IndexDistance typealias into the Collection protocol
Make the Indices types conform to the appropriate Collection protocol:
* Collection.Indices: Collection
* BidirectionalCollection.Indices: BidirectionalCollection
* RandomAccessCollection.Indices: RandomAccessCollection
Introduce (recursive) constraints that make the *Collection constraint
of SubSequence match that of its enclosing *Collection, e.g.,
MutableCollection.SubSequence conforms to MutableCollection.
Fixes rdar://problem/20715031 and more of SR-3453.
* 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
Part of ABI FIXME #99, this gives us some nice consistency that
ensures that slicing a SubSequence gives us another SubSequence. There
are two source-compatibility implications to this change:
* Collections now need to satisfy this property, which could not be
expressed in Swift 3. There might be some Collections that don't
satisfy this property, and will break with the Swift 4 compiler
*even in Swift 3 compatibility mode*. Case in point...
* The Lazy collection types were formulated as a lazy collection of
the base slice (e.g., LazyCollection<ArraySlice<T>>) rather than as
a slice of the lazy collection (e.g.,
Slice<LazyCollection<Array<T>>). The former doesn't meet the new
requirements, so change to the latter.
Address ABI FIXME #68 by using same-type constraints directly on an
associated type to describe the requirements on the Indices associated
type of the Collection protocol. ABI FIXMEs #89, #90, #91 are all in
StdlibUnittest, and provoke warnings once #68 is fixed, but it's nice
to clear them out.
Fixes SR-2121.
