- getAsDeclOrDeclExtensionContext -> getAsDecl
This is basically the same as a dyn_cast, so it should use a 'getAs'
name like TypeBase does.
- getAsNominalTypeOrNominalTypeExtensionContext -> getSelfNominalTypeDecl
- getAsClassOrClassExtensionContext -> getSelfClassDecl
- getAsEnumOrEnumExtensionContext -> getSelfEnumDecl
- getAsStructOrStructExtensionContext -> getSelfStructDecl
- getAsProtocolOrProtocolExtensionContext -> getSelfProtocolDecl
- getAsTypeOrTypeExtensionContext -> getSelfTypeDecl (private)
These do /not/ return some form of 'this'; instead, they get the
extended types when 'this' is an extension. They started off life with
'is' names, which makes sense, but changed to this at some point. The
names I went with match up with getSelfInterfaceType and
getSelfTypeInContext, even though strictly speaking they're closer to
what getDeclaredInterfaceType does. But it didn't seem right to claim
that an extension "declares" the ClassDecl here.
- getAsProtocolExtensionContext -> getExtendedProtocolDecl
Like the above, this didn't return the ExtensionDecl; it returned its
extended type.
This entire commit is a mechanical change: find-and-replace, followed
by manual reformatted but no code changes.
This saves us some expensive cross-referencing and caching in the runtime, and lets us reclaim the `isReflectable` bit from the context descriptor flags (since a null field descriptor is a suitable and more accurate indicator of whether a type is reflectable).
Certain uses of protocols only formally need the requirement
signature, not any of the method requirements. This results in IRGen
seeing a protocol where none of the members have been validated except
the associated types. Account for this by allowing ProtocolInfo to
only contain the layout for the base protocols and associated types,
if requested.
Note that this relies on the layout of a witness table always putting
the "requirement signature part" at the front, or at least at offsets
that aren't affected by function requirements.
rdar://problem/43260117
We also use this for field offset globals, which are not always
constant. I think in practice everything was getting set
correctly, but it was hard to follow the logic.
Introduce ExtensionDecl::getExtendedNominal() to provide the nominal
type declaration that the extension declaration extends. Move most
of the existing callers of the callers to getExtendedType() over to
getExtendedNominal(), because they don’t need the full type information.
ExtensionDecl::getExtendedNominal() is itself not very interesting yet,
because it depends on getExtendedType().
Rather than using getAllConformances() to emit all conformances for a
nominal type whenever we emit its type metadata, use
getLocalConformances() consistently--on the nominal type and on any
extension--to emit the conformances in the appropriate source files.
- `swift_getForeignTypeMetadata` is now a request/response function.
- The initialization function is now a completion function, and the
pointer to it has moved into the type descriptor.
- The cache variable is no longer part of the ABI; it's an
implementation detail of the access function.
- The two points above mean that there is no special header on foreign
type metadata and therefore that they can be marked constant when
there isn't something about them that needs to be initialized.
The only foreign-metadata initialization we actually do right now is
of the superclass field of a foreign class, and since that relationship
is a proper DAG, it's not actually possible to have recursive
initialization problems. But this is the right long-term thing to do,
and it removes one of the last two clients of once-based initialization.
As part of this, rename TypeMetadataRecordKind to TypeReferenceKind
and consistently give it three bits of storage.
The better modelling of these type references appears to have been
sufficient to make dynamic conformance checks succeed, which is good
but unexpected.
- 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
The central thrust of this patch is to get these metadata initializations
off of `swift_once` and onto the metadata-request system where we can
properly detect and resolve dependencies. We do this by first introducing
runtime support for resolving metadata requests for "in-place"
initializations (committed previously) and then teaching IRGen to actually
generate code to use them (this patch).
A non-trivial amount of this patch is just renaming and refactoring some of
existing infrastructure that was being used for in-place initializations to
try to avoid unnecessary confusion.
The remaining cases that are still using `swift_once` resolution of
metadata initialization are:
- non-generic classes that can't statically fill their superclass or
have resilient internal layout
- foreign type metadata
Classes require more work because I'd like to switch at least the
resilient-superclass case over to using a pattern much more like what
we do with generic class instantiation. That is, I'd like in-place
initialization to be reserved for classes that actually don't need
relocation.
Foreign metadata should also be updated to the request/dependency scheme
before we declare ABI stability. I'm not sure why foreign metadata
would ever require a type to be resolved, but let's assume it's possible.
Fixes part of SR-7876.
When accessing global variables defined in the REPL, lldb does not consult
debug info, so it does not see that the DW_OP_deref was emitted.
So instead, set a special bit on globals defined in the REPL which bypasses
resilience for them altogether.
Part of the fix <rdar://problem/39722386>.
This causes problems for cross-compilation -parse-stdlib tests that
emit debug info. At the moment we have zero of those, but we're
trying to add one.
Also, don't try to load new modules when recording imports. (This
isn't harmful, just inefficient.)
The other JIT modes all still build an entire local context into one LLVM module, so it's safe to form relative references, and necessary for reflection to work with private and local contexts. Only the integrated REPL needs this prohibition. Fixes rdar://problem/40607819.
@effects is too low a level, and not meant for general usage outside
the standard library. Therefore it deserves to be underscored like
other such attributes.
Because the runtime is compacted into the standard library, functions
which are normally imported are actually local definitions. Use module
level named metadata to identify the module as being the swift standard
library. Refactor the condition slightly to improve code readability.
This addresses SR-7107!
We already do this for witness tables, but the check was missing for metadata.
This problem caused unresolved symbols when interpreting with -O.
rdar://problem/40128897
- Add swift_getForeignWitnessTable to unique non-unique foreign type
witness tables
- IRGen: Call the foreign witness uniquing runtime function
rdar://24958043
SIL optimizations may rewrite profiling intrinsics in a way that IRGen
can't lower (r://39146527). Don't claim that a coverage mapping has a
guaranteed associated symbol table entry when this happens.
I have not added a test, as this is a defensive workaround until we can
land add a SIL verifier check that prevents profiling intrinsics from
being rewritten.
rdar://40133800
The layout of an enum type will only use spare bits if the
payload types have a fixed size in all resilience domains
where they are visible. In practice, this means that:
- If the enum is internal or resilient, we can use spare bits
if the payload types are fixed size from inside the current
module.
- If the enum is public and not resilient, we can use spare bits
if the payload types are fixed size from all resilience
domains.
The bug was that the 'fixed size in all resilience domains'
check was returning true for resilient types when the
-enable-resilience-bypass flag was on. This is wrong, because
this meant that building a module with and without
-enable-resilience-bypass could produce different lowerings
for enum types.
Fixes <rdar://problem/40034143>.
