Having package-name flag in non-package interfaces causes them to be built as if
belonging to a package, which causes an issue for a loading client outside of the
package as follows.
For example, when building X that depends on A with the following dependency chain:
X --> A --> B --(package-only)--> C
1. X itself is not in the same package as A, B, and C.
2. When dependency scanning X, and opening up B, because the scan target is in a
different package domain, the scanner decides that B's package-only dependency
on C is to be ignored.
3. When then finally building A itself, it will load its dependencies, but because
the .private.swiftinterface of A still specifies -package-name, when it loads
B, it will then examine its dependencies and deem that this package-only dependency
on C is required.
Because (2) and (3) disagree, we get an error now when building the private A textual interface.
rdar://130701866
A generic signature's `getInnermostGenericParams` will find the generic
parameters in the innermost scope. That's not quite right for printing
inverses, since we don't want to print an inverse for `T` when emitting
the generic signature of `f` below:
```swift
struct S<T: ~Copyable, E> {
func f() where E == Never {}
}
```
Since `f` has its own generic signature, but doesn't define any generic
parameters, it shouldn't have an inverse emitted. The solution here is
to filter inverses by depth of the generic parameter.
We also want to print _all_ of the inverses in other situations, rather
than just the innermost ones. This aids in debugging and other
tools like the API digester.
resolves rdar://130179698
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.
Serialize the `-public-autolink-library <name>` option to the
moduleinterface file because it can affect the LINK_LIBRARY entries in a
swiftmodule file. Without saving the option, the library won't be linked
when a module compiled from the moduleinterface is used.
This change marks the `-public-autolink-library` option as a module
interface option and reads it when building a swiftmodule by module
loader.
objcImpl extensions with final public members need to be printed into module interfaces, but with the @implementation attribute suppressed. That worked fine…but when we switched to the new syntax, we should also have suppressed the @objc attribute, and we mistakenly did not. Correct this oversight.
Fixes rdar://129178360.
Checking for the presence of a feature flag in order to allow syntax tends to
result in condfails when applied to `.swiftinterfaces`, since older compilers
that have this restriction may be used to compile newer interfaces where the
restriction has been lifted. Remove this restriction for non-escapable types
when typechecking an interface.
Resolves rdar://128577611
Some compilers have the NoncopyableGenerics feature enabled via
interesting mechanisms but do not have ConformanceSuppression. To
support such compilers, the NoncopyableGenerics feature must appear
before ConformanceSuppression in the list of features. Otherwise, when
parsing the portion of the swiftinterface corresponding to an entity
which involves both features, the first check will be for
NoncopyableGenerics (which that old compiler has) and the code inside
will involve ConformanceSuppression (which that old compiler does not
have).
rdar://128611158
VarDecls with `@_projectedValueProperty` have already had the property
wrapper transform applied. This only impacts swiftinterfaces, and if
a swiftinterface was produced against a Concurrency library that does
not declare `TaskLocal` as a macro, we need to ignore the macro to avoid
producing duplicate declarations. This is only needed temporarily until
all swiftinterfaces have been built against the Concurrency library
containing the new macro declaration.
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.
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
Ensure that when using noncopyable generics when building a module,
the compiler can re-ingest it and will pick the part guarded by
$NoncopyableGenerics.
verifies the concern in rdar://127701059
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
With the generalization of Optional to support noncopyable types, our
feature-guarding in swiftinterface files would double-print functions
that simply refer to the Optional type.
Since NoncopyableGenerics is a suppressible feature, by default
a second version of Optional and UnsafePointer are emitted into
swiftinterface files, where the ~Copyable generalization is stripped
away.
We can rely on that to avoid double-printing the function, if the types
substituted for the generic parameters are all Copyable.
We need a bit more checking for when
`@_disallowFeatureSuppression(NoncopyableGenerics)` is used, since this
trick relies on there always being a definition of the type we refer to,
whether the feature is enabled or not.
resolves rdar://127389991
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.
