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>.
Now that struct initializers "just" fall into the delegating case when
they're made inlinable, the only interesting case is class
initializers, which can be checked in a more direct way than what we
were doing before.
(and when the struct in question is non-fixed-layout, which was
already implemented)
This ensures that these initializers are never fieldwise in Swift 5
mode, which makes it safe for library authors to add new fields.
The -enable-testing flag makes ValueDecl::getEffectiveAccess()
say that internal declarations are public.
This would lead us to emit spurious diagnostics if a default
argument of an internal function referenced a private symbol,
for example, which is something we actually want to allow.
This is a second revision of the patch -- instead of changing
getEffectiveAccess() to take an extra parameter, this changes
getFormalAccessScope() instead.
Fixes <rdar://problem/32592973>.
