If a conformance is defined in an extension, we now look for
references to the conformance in types and expressions and
respect's the extension's availability (or deprecation, etc).
The conformance checker itself still needs to check conformance
availability of associated conformances and the like; that will
be a separate change.
Note that conformances defined on types don't require any
special handling, since they are as available as the
intersection of the conforming type and the protocol.
By default, we diagnose conformance availability violations
where the OS version is not sufficiently new as warnings, to
avoid breaking source compatibility. Stricter behavior where
these violations are diagnosed as errors is enabled by passing
the -enable-conformance-availability-errors flag. There are
test cases that run both with and without this flag. In the
future, we hope to make the stricter behavior the default,
since after all, violations here can result in link errors and
runtime crashes.
Uses of completely unavailable conformances are still always
diagnosed as errors, even when this flag is not passed in.
Progress on <rdar://problem/35158274>.
There's no need to check for that here, because we also run
diagnoseDeclRefExportability() on declarations referenced
from inlinable code.
This changes some diagnostics; we now produce the same diagnostic
for references to SPI types in declaration signatures and for
references to non-type SPI declarations in inlinable function bodies.
Also note that the old inlinable reference diagnostic no longer has
to handle the 'public' and 'open' access levels, which previously
happened for '@_spi'; so I changed those entries in the %select to
%error.
getFragileFunctionKind() would report that all initializers in
non-resilient public types were inlinable, including static
properties.
This was later patched by VarDecl::isInitExposedToClients(),
which was checked in diagnoseInlinableDeclRefAccess().
However, the latter function only looked at the innermost
DeclContexts, not all parent contexts, so it would incorrectly
diagnose code with a nested DeclContext inside of a static
property initializer.
Fix this by changing getFragileFunctionKind() to call
isInitExposedToClients() and simplifying
diagnoseInlinableDeclRefAccess().
This commit also introduces a new isLayoutExposedToClients()
method, which is similar to isInitExposedToClients(), except
it also returns 'true' if the property does not have an
initializer (and in fact the latter is implemented in terms
of the former).
Converting the innermost DeclContext into a Decl won't work if
the innermost DeclContext is the parent context of a VarDecl.
Instead, use the relevant bit of state from the ExportContext,
which is computed correctly.
This fixes a regression caused by an earlier commit in this PR
which our test suite did not catch.
The ExportContext describes the restrictions, if any, on what
declarations can be uttered in a specific place in the
program. Here, the place is either the signature of a
declaration, or the body of a function.
Today, we check conformance exportability in two places:
1) For inlinable function bodies: in availability checking
2) For types in inlinable declaration signatures: in availability checking
3) For types in non-inlinable declaration signatures: in ExportabilityChecker
I want to merge 2) and 3) together, and also generalize the conformance
exportability check to check conformance availability as well.
This is a preliminary refactoring towards achieving this goal.
```
class Generic<T> {
@objc dynamic func method() {}
}
extension Generic {
@_dynamicReplacement(for:method())
func replacement() {}
}
```
The standard mechanism of using Objective-C categories for dynamically
replacing @objc methods in generic classes does not work.
Instead we mark the native entry point as replaceable.
Because this affects all @objc methods in generic classes (whether there
is a replacement or not) by making the native entry point
`[dynamically_replaceable]` (regardless of optimization mode) we guard this by
the -enable-implicit-dynamic flag because we are late in the release cycle.
* Replace isNativeDynamic and isObjcDynamic by calls to shouldUse*Dispatch and
shouldUse*Replacement
This disambiguates between which dispatch method we should use at call
sites and how these methods should implement dynamic function
replacement.
* Don't emit the method entry for @_dynamicReplacement(for:) of generic class
methods
There is not way to call this entry point since we can't generate an
objective-c category for generic classes.
rdar://63679357
We had some duplicated logic between getResilienceExpansion() and
getFragileFunctionKind(). Clean this up by moving the latter into
AST, and re-implementing the former in terms of the latter.
This also fixes a crash in at least one case where these two
implementations had previously diverged.
Fixes <rdar://problem/60605117>.
Switch most callers to explicit indices. The exceptions lie in things that needs to manipulate the parsed output directly including the Parser and components of the ASTScope. These are included as friend class exceptions.
Like the last commit, SourceFile is used a lot by Parse and Sema, but
less so by the ClangImporter and (de)Serialization. Split it out to
cut down on recompilation times when something changes.
This commit does /not/ split the implementation of SourceFile out of
Module.cpp, which is where most of it lives. That might also be a
reasonable change, but the reason I was reluctant to is because a
number of SourceFile members correspond to the entry points in
ModuleDecl. Someone else can pick this up later if they decide it's a
good idea.
No functionality change.
Most of AST, Parse, and Sema deal with FileUnits regularly, but SIL
and IRGen certainly don't. Split FileUnit out into its own header to
cut down on recompilation times when something changes.
No functionality change.
Move around some code so that TypeChecker::validateType is now a utility
method of the type checker. This cleans up at least one request that no
longer needs to grab the type checker from the AST context.
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
This is like '@inlinable', except that the symbol does not have a public
entry point in the generated binary at all; it is deserialized and a copy
is always emitted into the client binary, with shared linkage.
Just like '@inlinable', if you apply this to an internal declaration it
becomes '@usableFromInline' automatically.
This uses the same mechanism as default arguments ever since Swift 4, so
it should work reasonably well, but there are rough edges with diagnostics
and such. Don't use this if you are not the standard library.
Fixes <rdar://problem/33767512>, <https://bugs.swift.org/browse/SR-5646>.
This patch mainly consolidates the functions used to check accessors vs.
other decls, and makes sure we check setter access as well as regular
decl access.
rdar://45217648
Static properties are not subject to the same restrictions as properties
whose initializers are exposed to clients in @_fixed_layout types.
rdar://45080912
- Treat protocol requirements just like associated types in how they
inherit usable-from-inline-ness, rather than special-casing them in
the check for inlinable code.
- Enum elements are already treated this way, so we can remove a
redundant check for that.
- Finally, start enforcing that 'dynamic' declarations need to be
'@usableFromInline' to be used in inlinable functions...in Swift 5
mode or resilient code. I didn't even add a warning in Swift 4/4.2
because it was illegal to use '@usableFromInline' on a 'dynamic'
declaration in Swift 4.2. (Oops.)
This has three principal advantages:
- It gives some additional type-safety when working
with known accessors.
- It makes it significantly easier to test whether a declaration
is an accessor and encourages the use of a common idiom.
- It saves a small amount of memory in both FuncDecl and its
serialized form.
We want stored property initializers of fixed layout structs to be
inlinable, so that inlinable initializers can be fully eliminated
by the optimizer.
This is the first step in fixing <rdar://problem/36454839>.
