If the extension adds conformance to an invertible protocol, it's
confusing for people to also infer conditional requirements on the
generic parameters for those invertible protocols. This came up in the
review of SE-427.
Removing the old, ad-hoc diagnostics code improves the diagnostics we
emit, since the existing diagnostics for missing conformances is already
pretty good.
rdar://127369509
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
We want to ensure that functions/methods themselves do not have sending mangled
into their names, but we do want sending mangled in non-top level positions. For
example: we do not want to mangle sending into a function like the following:
```swift
// We don't want to mangle this.
func test(_ x: sending NonSendableKlass) -> ()
```
But when it comes to actually storing functions into memory, we do want to
distinguish in between function values that use sending vs those that do not
since we do not want to allow for them to alias. Thus we want to mangle sending
into things like the following:
```swift
// We want to distinguish in between Array<(sending T) -> ()> and
// Array((T) -> ()>
let a = Array<(sending T) -> ()>
// We want to distinguish in between a global contianing (sending T) -> () and a
// global containing (T) -> ().
var global: (sending T) -> ()
```
This commit achieves that by making changes to the ASTMangler in getDeclType
which causes getDeclType to set a flag that says that we have not yet recursed
through the system and thus should suppress the printing of sendable. Once we
get further into the system and recurse, that flag is by default set to true, so
we get the old sending parameter without having to update large amounts of code.
rdar://127383107
The `-experimental-skip-all-function-bodies` flag is specified when producing
modules for indexing. These modules are not used for compilation, so it should
be safe to allow `-experimental-lazy-typecheck` and
`-experimental-skip-non-exportable-decls` as well without
`-enable-library-evolution`.
Resolves rdar://128706306
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
Compute, update and handle borrowed-from instruction in various utilities and passes.
Also, used borrowed-from to simplify `gatherBorrowIntroducers` and `gatherEnclosingValues`.
Replace those utilities by `Value.getBorrowIntroducers` and `Value.getEnclosingValues`, which return a lazily computed Sequence of borrowed/enclosing values.
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.
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.
Protocols with a superclass bound written as `protocol P where Self: C`
return null from getSuperclass(). Unqualified lookup only cares about
getSuperclassDecl(), so serialize that instead.
Fixes rdar://problem/124478687.
Deserialization may fail if a decl in a dependency changed type between the
time a swiftmodule was built and when it was imported. This can happen because
of changes to the SDK or use of C preprocessor macros. To help understand these
problems, note the specific types causing the mismatch when it leads to a
deserialization failure.
```
.../LibWithXRef.swiftmodule:1:1: error: reference to top-level
declaration 'foo' broken by a context change; the declaration kind of
'foo' from 'A' changed since building 'LibWithXRef'
1 │ A.foo
│ │ ├─ ...
│ ├─ note: a candidate was filtered out because of a type mismatch;
expected: '() -> ()', found: '(Int) -> Float'
```
Make sure we flush the diagnostics consumers to prevent the new
diagnostic style to buffer the deserialization errors without printing
them. These errors may be printed right before an `abort()`, which would
bypass the actual printing of the errors.
Take advantage of the new style to make these diagnostics more readable
as well.
```
.../LibWithXRef.swiftmodule:1:1: remark: reference to type 'MyType'
broken by a context change; 'MyType' was expected to be in 'A', but now
a candidate is found only in 'A_related'
1 │ A.MyType
│ ├─ remark: reference to type 'MyType' broken by a context change;
'MyType' was expected to be in 'A', but now a candidate is found only in
'A_related'
│ ├─ note: the type was expected to be found in module 'A' at
‘.../A.swiftmodule'
│ ├─ note: or expected to be found in the underlying module 'A'
defined at ‘.../module.modulemap'
│ ├─ note: the type was actually found in module 'A_related' at
‘.../A_related.swiftmodule'
│ ├─ note: the module 'LibWithXRef' was built with a Swift language
version set to 5.10 while the current invocation uses 4.1.50; APINotes
may change how clang declarations are imported
│ ├─ note: the module 'LibWithXRef' has enabled library-evolution; the
following file may need to be deleted if the SDK was modified:
‘.../LibWithXRef.swiftmodule'
│ ├─ note: declarations in the underlying clang module 'A' may be
hidden by clang preprocessor macros
│ ├─ note: the distributed module 'LibWithXRef' refers to the local
module 'A'; this may be caused by header maps or search paths
│ ╰─ note: the type 'MyType' moved between related modules; clang
preprocessor macros may affect headers shared between these modules
.../LibWithXRef.swiftmodule:1:1: note: could not deserialize type for
'foo()'
1 │ A.MyType
│ ╰─ note: could not deserialize type for 'foo()'
```
rdar://124700605
It's not currently clear whether this is a regression or just a test
that needs updating. For now it seems harmless to just update the test
rather than disable it.
