In non-library-evolution mode, gated behind the CheckImplementationOnly
feature flag, report references to structs marked with
`@_implementationOnly` from a fragile context. Preventing references
from inlinable functions and structs not marked `@_implementationOnly`.
Embedded mode use only binary swiftmodules for distribution, SPI will
always be visible. We can allow implicitly always-emit-into-client
function bodies from the embedded mode to references SPIs.
rdar://163519075
Access-level on imports don't hide the dependency in
non-library-evolution mode. We can allow implicitly
always-emit-into-client function bodies from embedded mode
to references the dependencies.
rdar://163519185
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.
Update logic finding the import to point in diagnostics to avoid relying
on the implicit import of the top-level module when importing a clang
submodule. A recent change avoids duplicating the implicit imports and
broke the old logic.
rdar://162151660
Consider functions in embedded mode to be fragile unless marked with
`@_neverEmitIntoClient`. Basically treating them as if they were
`@_alwaysEmitIntoClient` by default. A fragile function cannot reference
restricted imports such as `@_implementationOnly`, `internal import`,
etc.
We consider them as fragile only for type-checking, at the SIL level
they remain treated as normal functions like before. This allows the
later optimization to work as expected. We may want to likely align both
ends of the compiler once this is properly supported in sema.
This is enabled only in embedded. Fragile functions in library-evolution
are marked with attributes and are already checked. We do not need this
is non-embedded non-library-evolution as CMO handles inlining and
already takes into consideration `@_implementationOnly` imports.
Note: We'll need a similar check for memory layouts exposed to clients.
We can still see compiler crashes and miscompiles in this scenario. This
will apply to both embedded and non-library-evolution modes. That will
likely need to extend the `@_neverEmitIntoClient` attribute and may
require a staged deployment.
rdar://161365361
Declarations that are unavailable at runtime because of an `@available`
attribute referencing a custom domain that was imported `@_spiOnly` should be
hidden from public swiftinterface files in `-library-level=api` modules. For
remaining declarations that do get printed in the public swiftinterface, skip
printing any `@available` attribute that refers to the domains from those
`@_spiOnly` dependencies. This allows API developers to control declaration
visibility using availability defined by another module.
Resolves rdar://156512028.
This allows diagnostics to be more precise and will also support logic that
allows for special cases for `@available` attributes in exportability checking.
Also fixes a bug where the exportability of `@available` attributes attached to
extensions were diagnosed twice for slightly differing reasons.
To reduce code duplication, implement a convenience version of
`swift::recordRequiredImportAccessLevelForDecl()` that handles the common case
of recording required import access for a reference to a `ValueDecl`.
NFC.
The migration to `MemberImportVisibility` can be performed mechanically by
adding missing import declarations, so offer automatic migration for the
feature.
Resolves rdar://151931597.
Previously, the constraint solver would first attempt member lookup that
excluded members from transitively imported modules. If there were no viable
candidates, it would perform a second lookup that included the previously
excluded members, treating any candidates as unviable. This meant that if the
member reference did resolve to one of the unviable candidates the resulting
AST would be broken, which could cause unwanted knock-on diagnostics.
Now, members from transitively imported modules are always returned in the set
of viable candidates. However, scoring will always prioritize candidates from
directly imported modules over members from transitive imports. This solves the
ambiguities that `MemberImportVisibility` is designed to prevent. If the only
viable candidates are from transitively imported modules, though, then the
reference will be resolved successfully and diagnosed later in
`MiscDiagnostics.cpp`. The resulting AST will not contain any errors, which
ensures that necessary access levels can be computed correctly for the imports
suggested by `MemberImportVisibility` fix-its.
Resolves rdar://126637855.
When `MemberImportVisibility` is enabled, if the import that would bring a
member declaration into scope is missing it is diagnosed as an error. The
existing resilience diagnostics that would also diagnose the same problem in
contexts that are visible in the module interface are therefore superflous with
the feature enabled.
In anticipation of adding a new kind of missing import record to `SourceFile`,
clarify the purpose of the existing "missing imports" record with more specific
naming and documentation.
In anticipation of reusing minimum access level information for diagnostics
related to the `MemberImportVisibility` feature, refactor the way the type
checker tracks the modules which must be imported publicly. Recording minimum
access levels is no longer restricted to modules that are already imported in a
source file since `MemberImportVisibility` diagnostics will need this
information when emitting fix-its for modules that are not already imported.
Unblocks rdar://126637855.
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
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
This PR treats package access level as exportable, preventing
internally imported types from accidentally being declared in
package decl signatures.
Added package-specific cases to ExportabilityReason and
DisallowedOriginKind to track the validity of imported types
at use sites with package access scope. Added tests to cover
variety of use cases.
Resolves rdar://117586046&125050064&124484388&124306642
Now that the diagnostics are automatically errors in Swift 6, we don't need an
`-enable-conformance-availability-errors` flag to control whether unavailable
conformances are diagnosed as errors. Nobody was using the flag so it should be
safe to remove.
Part of rdar://88210812
Access levels on extensions are special. Let's make sure we report
public extensions referencing non-public imported types using the
preexisting general exportability checks.
Record and remark on the use of the import at the same time.
Using `-Rmodule-api-import` the compiler prints a remark about the
import bringing in every decl used in public function signatures or
inlinable code. It also remarks on the source of conformances where they
are used and the source of typealias underlying types.
Exportability checking logic detects when decls are referenced from API
or inlinable code. This duplicates the check applied for the access
level. Skip the exportability reports about non-public imports and keep
the more familiar access-level check.
Fix the note pointing to the import when using a package type in a
public declaration or inlinable code. We want a note on the import only
when it actually lowers the access level of the imported decl.
The note about a `package import` was simply be superfluous, while the
same note about a `public import` would trigger an assert later on.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
