Replace the `here` part of the generic exportability diagnostic for
variables with: `in a property declaration marked public or in a
'@frozen' or '@usableFromInline' context`.
The full diagnostic now looks like:
```
error: cannot use struct 'ImportedType' in a property declaration marked
public or in a '@frozen' or '@usableFromInline' context;
'HiddenDependency' has been imported as implementation-only
```
This should be improved further to support implicitly exported memory
layouts in non-library-evolution and embedded.
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
Exportability checking for non-public imports relies on classic
access-level checks for some of the work. However while conforming
to a local internal protocol from a public type is allow we should
disallow it for imported types, even when imported as internal.
Track exportability issues on conformances to protocols separately
from the general category. Use that information to improve the
diagnostics and report these issues for access-level on imports.
rdar://128420980
Let's point out the associated type with a separate note, so
that we can diagnose other availability failures, such as
deprecation and OS version availability.
Even if a nominal type does not have its own generic parameters,
we need to visit its conformances, because it might be defined
in a constrained extension or have a 'where' clause of its own.
Access control, availability and exportability checking missed these
because of a baked-in assumption that getGenericParams() == nullptr
rules out the presence of a trailing where clause.
We already ban all structs from declaring storage that comes from implementation-only imports. Until now we missed property wrappers, they were just dropped in deserialization.
Resolves rdar://problem/59403617
The logic I had here checked whether an extension used an
implementation-only type whenever there was a declaration within that
extension that needed checking...but unfortunately that included not
just PatternBindingDecls (whose access is filtered at a later step)
but things like IfConfigDecls (#if). Change this to only check
signatures of extensions with ABI-public members, something that is
tested once when visiting an ExtensionDecl.
Additionally, skip AccessorDecls entirely, since they'll be tested
as part of the corresponding subscript or var. This saves a duplicate
diagnostic.
rdar://problem/50541589
This includes both the types and the values (generic functions, etc)
used in the inlinable code. We get some effectively duplicate
diagnostics at this point because of this, but we can deal with that
at a future date.
Last part of rdar://problem/48991061
Okay, strictly we're checking the "signature conformances" of a newly-
declared conformance, but that wouldn't have fit on one line. This is
making sure that we don't have a requirement on an associated type (or
on the conforming type) that can only be satisfied using a conformance
in an implementation-only import.
These also create a dependency on the implementation module, even if
both the type and the protocol are public. As John puts it, a
conformance is basically a declaration that we name as part of another
declaration.
More rdar://problem/48991061
Based on the existing access checker for types used in decls. There's
a common skeleton here but we can't seem to get it out, so for now
add a third DeclVisitor to this file. On the plus side, checking this
alongside access is an easy way to make sure everything gets checked.
Part of rdar://problem/48991061
