This simplifies the handling of the subdirectories in the SIL and
SILOptimizer paths. Create individual libraries as object libraries
which allows the analysis of the source changes to be limited in scope.
Because these are object libraries, this has 0 overhead compared to the
previous implementation. However, string operations over the filenames
are avoided. The cost for this is that any new sub-library needs to be
added into the list rather than added with the special local function.
Specifically, I split it into 3 initial categories: IR, Utils, Verifier. I just
did this quickly, we can always split it more later if we want.
I followed the model that we use in SILOptimizer: ./lib/SIL/CMakeLists.txt vends
a macro (sil_register_sources) to the sub-folders that register the sources of
the subdirectory with a global state variable that ./lib/SIL/CMakeLists.txt
defines. Then after including those subdirs, the parent cmake declares the SIL
library. So the output is the same, but we have the flexibility of having
subdirectories to categorize source files.
Since the return value of getAccessor() depends on mutable state, it
does not make sense in the request evaluator world. Let's begin by
removing some utility methods derived from getAccessor(), replacing
calls to them with calls to getAccessor().
This is in preparation for verifying that when ownership verification is enabled
that only enums and trivial values can have any ownership. I am doing this in
preparation for eliminating ValueOwnershipKind::Trivial.
rdar://46294760
We already assume in the given static method that the module is a non-null
pointer. So rather than us indirecting a ref to a pointer and then dereferencing
the pointer, we instead use the ref in the module implementation and dereference
the pointer.
rdar://46294760
We want removing a property override to be a resilient change, so
keypaths should not reference them, preferring to reference the
base declaration instead.
- Move the filter checks in SILGen for skipping emitting certain property descriptors into the AbstractStorageDecl::exportsPropertyDescriptor() predicate, to ensure that TBDGen and SILGen are in sync
- Fix the linkage of property descriptors to be based on the getter's linkage rather than the property's, since a property may be internal but have usableFromInline accessors
SILModules built for the debugger have special powers to access
metadata for types in other files/modules. Thanks to John McCall for
suggesting the fix. This should fix a verifier failure in the lldb
testsuite. The reason why it wasn't caught during PR testing is that
this test wasn't run as part of the standard swift-pr cycle. I'm
going to submit another PR in lldb next to make sure it runs (and,
therefore, we can catch other regressions).
<rdar://problem/40336275>
Fixed-ABI means that we can do value operations on the type without
any metadata: value-allocations, copies, and destroys. It's currently
equivalent to being fixed-size, but (1) being fixed-size isn't useful
by itself at the SIL level and (2) you can imagine resilience or generics
micro-optimizations where there's like an attribute that tells us the
size of a type without actually telling us how to copy it. All types
are fixed-ABI except:
- layout-unconstrained generic types,
- resilient value types, and
- value types which contain a subobject of such a type (except within
indirect enum cases).
ABI-accessible means that we can perform value operations at all.
We might not be able to if the type is not fixed-ABI and it is private
to a different file (in non-WMO builds) or internal to a different
module, because in such cases we will not be able to access its metadata.
In general, we can't use such types `T` directly, but we may be able to
use types `C` that contain such types as subobjects. Furthermore, we
may be reasonably exposed to SIL that performs operations that treat `C`
as non-opaque, e.g. if `C` is frozen (as it will be by default for
modules in Swift 5). We can still achieve correctness in these cases
as long as we don't either:
- inline code that contains value operations on `T` or
- attempt to recursively expand a value operation on `T` into value
operations on its subobjects.
The SIL optimizer currently never tries to expand value operations on
objects in memory. However, IRGen always recursively expands value
operations on frozen types; that will be fixed in a follow-up patch.
The SIL verification that I've added here is definitely incomplete.
- The overload of operator^ on FormalLinkage, while cute, was only used
in this one place, and does not behave like an XOR.
- The structural type walk was totally unnecessary in the first place,
because we were only ever calling getTypeLinkage() with builtin types
and nominal types.
- Furthermore, the structural type walk was doing the wrong thing with
nested nominal types, because the linkage of a nested type A.B
should not be the intersection of the linkage of A and A.B. If A is an
imported type and A.B is defined in an extension of A, we would give
the metadata of A.B shared linkage, which is wrong.
The witness table had shared linkage, but we weren't serializing them,
which would cause linking errors if we emitted a reference to such a
witness table from a different module than the one where it was first
defined, as a result of deserializing and optimizing SIL.
This issue was introduced when SIL witness table serialization was
made conditional on the -sil-serialize-witness-tables flag, which is
normally only enabled for the standard library.
When the flag was added, existing tests were updated to pass the
flag, which masked the issue. Remove the flag from existing tests,
ensure that imported witness tables are still [serialized], and add
a new test specifically for the behavior enabled by this flag.
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
Rename AccessibilityAttr to AccessControlAttr and
SetterAccessibilityAttr to SetterAccessAttr, then track down the last
few uses of "accessibility" that don't have to do with
NSAccessibility. (I left the SourceKit XPC API alone because that's
supposed to be more stable.)
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
This commit changes the 'Accessibility' enum to be named 'AccessLevel'.
A lot of files transitively include Expr.h, because it was
included from SILInstruction.h, SILLocation.h and SILDeclRef.h.
However in reality most of these files don't do anything
with Exprs, especially not anything in IRGen or the SILOptimizer.
Now we're down to 171 files in the frontend which depend on
Expr.h, which is still a lot but much better than before.
For example, if an internal type conforms to a public protocol, the witness table should get internal linkage.
Previously we only considered the visibility of the protocol.
Fragile witness tables still have to get public symbol linkage. This is now handled in IRGen (like we do it for functions).
One minor revision: this lifts the proposed restriction against
overriding a non-open method with an open one. On reflection,
that was inconsistent with the existing rule permitting non-public
methods to be overridden with public ones. The restriction on
subclassing a non-open class with an open class remains, and is
in fact consistent with the existing access rule.
'fileprivate' is considered a broader level of access than 'private',
but for now both of them are still available to the entire file. This
is intended as a migration aid.
One interesting fallout of the "access scope" model described in
758cf64 is that something declared 'private' at file scope is actually
treated as 'fileprivate' for diagnostic purposes. This is something
we can fix later, once the full model is in place. (It's not really
/wrong/ in that they have identical behavior, but diagnostics still
shouldn't refer to a type explicitly declared 'private' as
'fileprivate'.)
As a note, ValueDecl::getEffectiveAccess will always return 'FilePrivate'
rather than 'Private'; for purposes of optimization and code generation,
we should never try to distinguish these two cases.
This should have essentially no effect on code that's /not/ using
'fileprivate' other than altered diagnostics.
Progress on SE-0025 ('fileprivate' and 'private')
Don't hardcode linkage of default witness thunks, addressing a FIXME.
This will allow us to emit default witness thunks for requirements of
internal protocols, too.
As there are no instructions left which produce multiple result values, this is a NFC regarding the generated SIL and generated code.
Although this commit is large, most changes are straightforward adoptions to the changes in the ValueBase and SILValue classes.
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
Getting the protocols of an arbitrary type doesn't make sense, so start phasing this out by introducing specialized entry points that do make sense:
- get the inherited protocols of a ProtocolDecl
- get the conforming protocols for an associated type or generic
type parameter
- (already present) ask for the protocols to which a nominal type conforms
Swift SVN r26411
A type in an extension doesn't inherit linkage from its parent. In particular, if an extension adds a nested type to an imported class, we don't want that nested type to have unique linkage. Fixes rdar://problem/19792174.
Swift SVN r25191
Instead, just fall through to the normal public/internal/private switch
added in the previous commit. Local declarations are always private.
Make sure we emit all local declarations by using the list in the SourceFile,
rather than walking the AST (which missed a few cases and was less efficient
anyway).
As an exception, declarations without accessibility at all still get private
linkage. These are things like local variables that don't get accessed by
symbol, even when using the debugger.
rdar://problem/19623016
Swift SVN r24839
Easy cut down on exported symbols. Unless a private type is referenced in
an inlineable function, there's no way to generate a reference to it
outside of the current file, except in the debugger. (That last bit is why
we can't use fully private linkage, which would keep the symbol out of the
symbol table completely.)
We should be doing this for "internal" declarations as well, but the
standard library /does/ have references to internal types in inlineable
functions, and also has tests that directly access these types.
Swift SVN r24838
