Implement the @export(implementation) and @export(interface) attributes
to replace @_alwaysEmitIntoClient and @_neverEmitIntoClient. Provide a
warning + Fix-It to start staging out the very-new
@_neverEmitIntoClient. We'll hold off on pushing folks toward
@_alwaysEmitIntoClient for a little longer.
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
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.
Availability macros are rejected from library-evolution inlinable code
as the compiler didn't know how to print them in the swiftinterface.
This isn't a concern with the embedded style of fragile functions, we
can allow availability macros there.
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
