When swift dependency scanner first finds a binary module for a testable
import, verify if the module is built for enable-testing or not. If not,
keeps searching in case there is a second testable binary module in the
search path.
Previously, the first binary module will always be accepted by scanner
and rely on the importer to provide a good diagnostics. Now the scanner
will emit a warning before continue searching, so user understands why
the binary in the search path is not taken.
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
Access-level on imports limit where decls from the target module can
be referenced. This is reported by the typical error about and a note
on the import. However, when using an IDE and editing a large file,
the note on the import is easy to miss. Address this by duplicating
the information on the error line as well so it's never out of the
current viewport.
rdar://119438201
Adoption InternalImportsByDefault provides a safe access-level by default
to imports, as such ambiguities are not a risk and showing this warning is
superflous. When this warning is shown, make sure we note this alternative.
Report uses of `@_implementationOnly` in resilient modules as deprecated.
With a fixit to replace it with `internal` or delete it when imports
are internal by default.
Uses of `@_implementationOnly` in non-resilient modules is already reported
as being unsafe.
Package decls were made to be resilient at the definition
site by default. By allowing the attributes to be applied
to package decls, we can enable non-resilient access.
Resolves rdar://125169361
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.
Sometimes, quotes or an "aka" for a type are not desirable in a
diagnostic, such as one describing a Requirement. This modifier
suppresses such additional formatting a Type in a diagnostic.
The attribute declares that a struct contains "sensitive" data.
It enforces that the contents of such a struct value is zeroed out at the end of its lifetime.
In other words: the content of such a value is not observable in memory after the value's lifetime.
Also add an experimental feature `Sensitive` with which the attribute can be enabled.
Teach scanner to pick and choose binary modules correctly based on if it
is testable import or not. Some situations that scanner need to be
careful when testable is involved:
* When it is a regular import, it should not import binary modules that
are built with -enable-testing, it should prefer interfaces if that is
available.
* When testable import, it should only load binary module and it should
make sure the internal imports from binary modules are actually
required for testable import to work.
If a testable import only find a regular binary module, dependency
scanner currently will just preceed with such module and leave the
diagnostics to swift-frontend, because the alternative (failed to find
module) can be confusing to users.
rdar://125914165
Remove a diagnostic about conforming to Copyable now that a standard one
is emitted.
Also reenable the Sema/bitwise_copyable.swift test.
rdar://125934050
It doesn't really make sense for a conditional conformance requirement
for `Copyable` to depend on any other requirement other than other
`Copyable` conformance requirements.
resolves rdar://124967739
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.
Noncopyable types were prevented from having failable initializers
because `Optional` itself didn't support noncopyable types. Now
`Optional` does, so lift this restriction and add a test.
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.
