The basic inheritance clause emission in ASTPrinter operates on
InheritedEntry's, but does not canonicalize types. It's been
designed to consider an entire composition unprintable because one
member is unprintable (e.g., the protocol is not public).
This rejection is what was causing `~Copyable` in some compositions to
be missing from interface files (rdar://126090425). Fixing that is the
purpose of this patch.
What happens, then, if you mix public and nonpublic protocols in a
composition? A second facility called the InheritedProtocolCollector
later does find the public protocols, and emits extensions at the end of
the interface file to declare the additional conformances the ininitial
declaration printer missed.
We can't generally emit `~Copyable` on an extension, so the fix can't
happening there. Refactoring things so there's one source of truth about
the protocols being printed is a sizable refactoring that I will defer
for another time.
resolves rdar://126090425
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
We still only parse transferring... but this sets us up for adding the new
'sending' syntax by first validating that this internal change does not mess up
the current transferring impl since we want both to keep working for now.
rdar://128216574
The standard library defines
```
protocol BitwiseCopyable {}
typealias _BitwiseCopyable = BitwiseCopyable
```
For current compilers, `BitwiseCopyable` is a "known protocol".
For older compilers, it is not; instead `_BitwiseCopyable` is. So
print the following into the swiftinterface for those older compilers:
```
protocol _BitwiseCopyable {}
typealias BitwiseCopyable = _BitwiseCopyable
```
rdar://127755503
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.
When printing declarations with `NoncopyableGenerics2` suppressed we must avoid
printing the `@_preInverseGenerics` attribute and any `borrowing` or
`consuming` parameter ownership modifiers.
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.
Generated interfaces for Clang modules used to try printing normal
comments between decls extracted from the header text. That was because
doc-comment was not common in C/ObjC headers. But mainly because of
"import as member feature" Clang decls aren't printed in the order as
they appear in the header file, the logic determinig which comment
belongs to which decl was not working property. We've decided to remove
that feature and only print the proper doc-comments as it has been
getting common.
rdar://93731287
LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
language feature, and suppress it for `Clock.measure`.
This allows the _Concurrency swiftinterface file to continue building with
compilers that do not support `OptionalIsolatedParameters`. The feature
suppression drops the `isolated` keyword and replaces `#isolation` with
`nil`.
Allow `@_implements` to be expressed in an extension of the protocol in
which the associated type is defined. Use this to uncomment an
intended use of `@_implements` in `Sequence` that could be used to
replace a longstanding hack for associated type inference.
Since this change means that the standard library module interface
won't be accepted by older compilers, introduce a suppressible feature
ssociatedTypeImplements` that covers the use of `@_implements` on type
declarations. This will hide the `@_implements` attribute from older
compilers.
We preserve the current semantics that we have today by requiring that either all SILResultInfo are transferring or none are transferring. This also let me swap to @sil_transferring representation.
I did both of these things to fix SIL issues around transferring.
It also ensures that we now properly emit
Our standard conception of suppressible features assumes we should
always suppress the feature if the compiler doesn't support it.
This presumes that there's no harm in suppressing the feature, and
that's a fine assumption for features that are just adding information
or suppressing new diagnostics. Features that are semantically
relevant, maybe even ABI-breaking, are not a good fit for this,
and so instead of reprinting the decl with the feature suppressed,
we just have to hide the decl entirely. The missing middle here
is that it's sometimes useful to be able to adopt a type change
to an existing declaration, and we'd like older compilers to be
able to use the older version of the declaration. Making a type
change this way is, of course, only really acceptable for
@_alwaysEmitIntoClient declarations; but those represent quite a
few declarations that we'd like to be able to refine the types of.
Rather than trying to come up with heuristics based on
@_alwaysEmitIntoClient or other sources of information, this design
just requires the declaration to opt in with a new attribute,
@_allowFeatureSuppress. When a declaration opts in to suppression
for a conditionally-suppressible feature, the printer uses the
suppression serially-print-with-downgraded-options approach;
otherwise it uses the print-only-if-feature-is-available approach.
[region-isolation] Transferring results shouldn't have the following error emitted: "non-sendable type 'NonSendableKlass' returned by implicitly asynchronous call to main actor-isolated function cannot cross actor boundary"
Suppressing this feature doesn't disable the use of new syntax in the
normal way. Instead, it introduces `@rethrows` on the
AsyncIteratorProtocol and AsyncSequence protocols, so that older
compilers can still use the async sequences generated by newer
compilers and standard libraries.
Fixes the rest of rdar://123782658
The newly-introduced associated type `AsyncSequence.Failure` must
always be equivalent to the `Failure` type of the
`AsyncIteratorProtocol`. If the `AsyncSequence` type itself defines a
nested `Failure` type (say, for another purpose), associated type inference
would pick it and reject the `AsyncSequence`, causing a source compatibility
problem.
Work around the issue in two ways. First, always infer the type
witness for `AsyncSequence.Failure` from the type witness for
`AsyncIteratorProtocol.Failure`, so they can't be out of sync. This
means that we'll never even consider a nested `Failure` type in the
`AsyncSequence`-conforming type. This hack only applies prior to Swift 6.
Second, when we have inferred a `Failure` type and there is already
something else called `Failure` within that same nominal type, don't
print the inferred typelias into a module interface because it will
cause a conflict.
Fixes rdar://123543633.
Specifically:
1. Previously when printing we would not put a space after transferring.
2. When a function type has a transferring result, we wouldn't print it when dumping.
