We are leaving this as an open part of the design space. In the mean time if
people need a +0 parameter, they can use __shared with sending.
rdar://129116182
TLDR: This makes it so that we always can parse sending/transferring but changes
the semantic language effects to be keyed on RegionBasedIsolation instead.
----
The key thing that makes this all work is that I changed all of the "special"
semantic changes originally triggered on *ArgsAndResults to now be triggered
based on RegionBasedIsolation being enabled. This makes a lot of sense since we
want these semantic changes specifically to be combined with the checkers that
RegionBasedIsolation turns on. As a result, even though this causes these two
features to always be enabled, we just parse it but we do not use it for
anything semantically.
rdar://128961672
Teach dependency scanner to report all the module canImport check result
to swift-frontend, so swift-frontend doesn't need to parse swiftmodule
or parse TBD file to determine the versions. This ensures dependency
scanner and swift-frontend will have the same resolution for all
canImport checks.
This also fixes two related issues:
* Previously, in order to get consistant results between scanner and
frontend, scanner will request building the module in canImport check
even it is not imported later. This slightly alters the definition of
the canImport to only succeed when the module can be found AND be
built. This also can affect the auto-link in such cases.
* For caching build, the location of the clang module is abstracted away
so swift-frontend cannot locate the TBD file to resolve
underlyingVersion.
rdar://128067152
Allow lifetime depenendence on types that are BitwiseCopyable & Escapable.
This is unsafe in the sense that the compiler will not diagnose any use of the
dependent value outside of the lexcial scope of the source value. But, in
practice, dependence on an UnsafePointer is often needed. In that case, the
programmer should have already taken responsibility for ensuring the lifetime of the
pointer over all dependent uses. Typically, an unsafe pointer is valid for the
duration of a closure. Lifetime dependence prevents the dependent value from
being returned by the closure, so common usage is safe by default.
Typical example:
func decode(_ bufferRef: Span<Int>) { /*...*/ }
extension UnsafeBufferPointer {
// The client must ensure the lifetime of the buffer across the invocation of `body`.
// The client must ensure that no code modifies the buffer during the invocation of `body`.
func withUnsafeSpan<Result>(_ body: (Span<Element>) throws -> Result) rethrows -> Result {
// Construct Span using its internal, unsafe API.
try body(Span(unsafePointer: baseAddress!, count: count))
}
}
func decodeArrayAsUBP(array: [Int]) {
array.withUnsafeBufferPointer { buffer in
buffer.withUnsafeSpan {
decode($0)
}
}
}
In the future, we may add SILGen support for tracking the lexical scope of
BitwiseCopyable values. That would allow them to have the same dependence
behavior as other source values.
A few things:
1. Internally except for in the parser and the clang importer, we only represent
'sending'. This means that it will be easy to remove 'transferring' once enough
time has passed.
2. I included a warning that suggested to the user to change 'transferring' ->
'sending'.
3. I duplicated the parsing diagnostics for 'sending' so both will still get
different sets of diagnostics for parsing issues... but anywhere below parsing,
I have just changed 'transferring' to 'sending' since transferring isn't
represented at those lower levels.
4. Since SendingArgsAndResults is always enabled when TransferringArgsAndResults
is enabled (NOTE not vis-a-versa), we know that we can always parse sending. So
we import "transferring" as "sending". This means that even if one marks a
function with "transferring", the compiler will guard it behind a
SendingArgsAndResults -D flag and in the imported header print out sending.
rdar://128216574
This protocol appears in the stdlib as scaffolding for the
`NonescapableTypes` feature, which is still experimental and not gone
through evolution as an approved addition to the stdlib.
Rather than delete it from the stdlib, because it needs to still remain
to support that feature work, gate references to it behind a feature
flag.
Additionally, prevent documentation from seeing this declaration.
rdar://126705184
Add the machinery to support suppression of inference of conformance to
protocols that would otherwise be derived automatically.
This commit does not enable any conformances to be suppressed.
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
The model for associated types hasn't been fully worked-out for
noncopyable generics, but there is some support already that is being
used by the stdlib for an internal-only (and rather cursed) protocol
`_Pointer` to support `UnsafePointer`, etc.
This patch gates the existing experimental support for associated types
behind a feature flag. This flag doesn't emit feature-guards in
interfaces, since support for it is tied closely to NoncopyableGenerics
and has been there from its early days.
Ensure that we're properly parsing suppressed-conformance constraints
in expression contents and in metatypes. This allows types like `any
~Copyable` in expression context as well as types like `any
~Copyable.Type`.
While we're here, ensure that existentials that involve
suppressed-conformance constraints are spelled with `any`.
Fixes rdar://123728228.
Implement parser and type-expression folding semantics for invertible
protocols, so that one can write (e.g.) `[any ~Copyable]` as a type
within expression context.
Fixes rdar://125201146.
This patch adds "_multithreaded" as a valid `_runtime` argument and
sets it when the target is `wasm32-unknown-wasi-threads` or other
non-none OS targets.
Pitch - https://github.com/apple/swift-evolution/pull/2305
Changes highlights:
dependsOn(paramName) and dependsOn(scoped argName) syntax
dependsOn(paramName) -> copy lifetime dependence for all parameters/self except
when we have Escapable parameters/self, we assign scope
lifetime dependence.
Allow lifetime dependence on parameters without ownership modifier.
Always infer copy lifetime dependence except when we have
Escapable parameters/self, we infer scope lifetime dependence.
Allow lifetime dependence inference on parameters without ownership modifier.
The compiler treats version tuples that are all zeros as empty, or the same as
not having a version. Diagnose attempts to specify all-zeroes versions in
attributes and availability queries to prevent surprising behavior.
Resolves rdar://124661151
Previously, diagnostics for arguments of platform conditions (e.g.
'os(macOS)') used to point the condition name position instead of the
argument position.
Adjust the position to the start of the argument.
rdar://124160048
Lifetime specifiers before parameter names were disallowed in Swift 3 (SE-0031).
`isolated`, `transferring` and `_const` got added after Swift 3 without a diagnostic to disallow them before parameter names.
