Types that have "value semantics" should not have lexical lifetimes.
Value types are not expected to have custom deinits. Are not expected to
expose unsafe interior pointers. And cannot have weak references because
they are structs. Therefore, deinitialization barriers are irrelevant.
rdar://107076869
The _Copyable constraint was implemented as a marker protocol.
That protocol is part of the KnownProtocol's in the compiler.
When `ASTContext::getProtocol(KnownProtocolKind kind)` tries
to find the ProtocolDecl for Copyable, it will look in the
stdlib module (i.e., Swift module), which is where I initially
planned to put it.
That created problems initially when some regression tests
use `-parse-stdlib` failed to do that protocol lookup, which is
essential for adding the constraint (given the current implementation).
That led to believe we need to pull Copyable out of the stdlib, but that's
wrong. In fact, when building the Swift module itself, we do `-parse-stdlib`
but we also include `-module-name Swift`. This causes the _Copyable protocol
defined in the Stdlib to be correctly discovered while building the stdlib
itself (see the test case in this commit). So, the only downside of
having the Copyable protocol in the Stdlib is that `-parse-stdlib` tests
in the compiler can't use move-only types correctly, as they'll be
allowed in generic contexts. No real program would build like this.
Until I have time to do a further refactoring, this is an acceptable trade-off.
fixes rdar://104898230
Users should not do this:
class C {
func getRetained() {
let unmanaged = Unmanaged.passUnretained(self)
//... maybe some condition
unmanaged.retain()
}
}
But that should be obvious, and apparently this comment doesn't help.
Unmanaged.passRetained was originally implemented as:
- store the passed referenced into an unowned(unsafe) reference
- (the reference will now be released if the store is the last use)
- reload the unowned(unsafe) reference
- retain the reloaded reference
It should be implemented as:
- retain the passed reference
- store the passed reference to an unowned(unsafe) reference
Fixes rdar://105609600
(🔥 non-deterministic miscompile in stdlib's
_StringGuts.populateBreadcrumbs)
Speculatively fixing this to rule out potential miscompiles.
The compiler needs to know if a reference is being materialized out of
thin air. The proper way to do that is with the Unmanaged API.
Under the hood, this forces the reference into an "unowned(unsafe)"
variable which the reference must be reloaded from. That tells the
compiler that it can't optimize some seemingly unrelated object which
the reference may happen to refer to at runtime.
/// Warning: Casting from an integer or a pointer type to a reference type
/// is undefined behavior. It may result in incorrect code in any future
/// compiler release. To convert a bit pattern to a reference type:
/// 1. convert the bit pattern to an UnsafeRawPointer.
/// 2. create an unmanaged reference using Unmanaged.fromOpaque()
/// 3. obtain a managed reference using Unmanaged.takeUnretainedValue()
/// The programmer must ensure that the resulting reference has already been
/// manually retained.
This is a wild guess at what might be causing our persistent, random
String failures on the main branch:
```
Swift(macosx-x86_64) :: Prototypes/CollectionTransformers.swift
Swift(macosx-x86_64) :: stdlib/NSSlowString.swift
Swift(macosx-x86_64) :: stdlib/NSStringAPI.swift
Swift(macosx-x86_64) :: stdlib/StringIndex.swift
Swift-validation(macosx-x86_64) :: stdlib/String.swift
Swift-validation(macosx-x86_64) :: stdlib/StringBreadcrumbs.swift
Swift-validation(macosx-x86_64) :: stdlib/StringUTF8.swift
```
FWIW, it appears this is *not* caused by https://github.com/apple/swift/pull/62717:
that change has also landed on release/5.8, and I haven’t seen these
issues on that branch.
Our atomic breadcrumbs initialization vs its non-atomic loading
gives me an uneasy feeling that this may in fact be a long standing
synchronization issue that is only now causing problems (for whatever
reason). I am unable to reproduce these issues locally, so this guess
may be (and probably is) wildly off the mark, but this PR is likely
to be a good idea anyway, if only to rule out this possibility.
rdar://104751936
Since values of generic type are currently assumed to always
support copying, we need to prevent move-only types from
being substituted for generic type parameters.
This approach leans on a `_Copyable` marker protocol to which
all generic type parameters implicitly must conform.
A few other changes in this initial implementation:
- Now every concrete type that can conform to Copyable will do so. This fixes issues with conforming to a protocol that requires Copyable.
- Narrowly ban writing a concrete type `[T]` when `T` is move-only.
It does not compile in this mode.
```
error: no exact matches in call to instance method 'appendInterpolation'
owner: \(repr._objectIdentifier!), \
```
Key paths can store an offset or a pointer in the same field. On 32-bit, the field is considered to be an offset when it's less than the 4kB zero page, and a pointer otherwise.
The check uses a signed comparison, so pointers in the top half of memory would look like negative offsets. Add a check that the offset is zero or positive to avoid this.
rdar://103886537
Moves a `//` comment up above a `///` documentation comment, since the latter needs to be attached directly to the declaration or it won't be picked up as documentation.
