Double-underscored names are reserved for the C++ "implementation"
(language and standard library). Even though "__Consuming" isn't
likely to be part of the C++ standard any time soon, we should follow
the rules.
Note that the API digester will continue to use the string
"__Consuming" for now, even though the underscores aren't really
significant, to avoid invalidating existing dumps.
No functionality change.
This means that we no longer have the invariant that the extendedType always
contains the generic parameters. So we need to fix the assertions/test cases
for it.
The only place this was used in Decl.h was the failability kind of a
constructor.
I decided to replace this with a boolean isFailable() bit. Now that
we have isImplicitlyUnwrappedOptional(), it seems to make more sense
to not have ConstructorDecl represent redundant information which
might not be internally consistent.
Most callers of getFailability() actually only care if the result is
failable or not; the few callers that care about it being IUO can
check isImplicitlyUnwrappedOptional() as well.
This flag is set by DefinitInitialization if the lifetime of the stored value is controlled dynamically.
If the flag is set, it's not (easily) possibly to statically calculate the lifetime of the stored value.
This indicates that the "self" argument to the current function is always dynamically of the exact
static base class type, allowing metadata accesses in IRGen to use the local self metadata to answer
metadata requests for the class type. Set this attribute on allocating entry points of designated
inits, which is one of the most common places where we emit redundant metadata accesses.
Implicit accessors are sometimes transparent for performance reasons.
Previously this was done in Sema by maybeMarkTransparent(), which would
add a TransparentAttr. Replace this with a request.
Once accessors are no longer listed as members of their parent context,
a failure to deserialize a VarDecl or SubscriptDecl needs to create a
MissingMemberDecl with the total number of vtable entries expected for
all of the accessors of the storage.
Note that until the accessor change actually lands, we always compute
the expected number of vtable entries as 0.
...which allows the AST printer to correctly choose whether to print
it, which means it can be printed in a module interface in a non-WMO
build, which is necessary for @objc enums to have a correct run-time
representation when clients use that interface.
rdar://problem/53469608
Previously we would copy this attribute from a superclass to the
subclass when validating a subclass. However, this is only correct
if the superclass is always guaranteed to have been validated
before the subclass.
Indeed, it appears this assumption is no longer true, so we would
sometimes lose track of the attribute, which would result in SILGen
failing to emit the ivar initializer entry point.
Instead, check for the attribute as part of the superclass walk
in checkAncestry(), ensuring the result is always up to date, correct,
and cached.
As a follow-up, we should also convert checkAncestry() into a
request, but I'm not doing that here to keep the fix short.
Fixes <rdar://problem/50845438>.
If a protocol inherits from a protocol that can't be loaded, drop it
entirely. Similarly, if it has requirements that reference types in
other modules that can't be loaded, drop the protocol entirely---at
least for now, we don't want to deal with a protocol that exists but
has the wrong requirement signature. That "in other modules" isn't
perfect, but it avoids cases where two protocols depend on each other.
Unfortunately, it means the compiler may still get into exactly the
situation above if a protocol depends on another protocol in the same
module, and /that/ protocol can't be loaded for some other reason. But
it's progress.
This comes up when referencing implementation-only-imported protocols
from non-public protocols, but is also just general deserialization
recovery goodness.
rdar://problem/52141347
When the outermost property wrapper associated with a property has a
`wrapperValue`, create the projection property (with the `$` prefix)
at the same access level as the original property. This puts the
wrapped-value interface and the projection interface at the same level.
The newly-introduced @_projectionValueProperty attribute is implicitly
created to establish the link between the original property and the
projection value within module interfaces, where both properties will
be explicitly written out.
We don't need to serialize the protocol's superclass, we can compute it from the
generic signature. Previously, we would drop the superclass while
serializing because we didn't check the generic signature in
SuperclassTypeRequest, which would cause us to cache `NULL` when we
called `setSuperclass` for a protocol with a superclass constraint.
Fixes rdar://50526401
That is, if a struct's generic requirements can't be deserialized,
drop the struct. This is the same logic that's already in play for
enums and (as of the previous commit) classes, so it should be pretty
well tested by now. (Hence the sole test I'm adding here, snuck into
superclass.swift because it's a superclass /constraint/ being tested.)
I don't know of any outstanding issues caused by this, but it was
weird to have it for enums and classes but not structs, so here we
are.
...instead of crashing. Also drop the class if its generic
requirements depend on a type that can't be loaded (instead of
crashing).
rdar://problem/50125674
Similar to 517f5d6b6a, the "shadowed" terminology didn't end up
describing the most common use of the feature; there is pretty much no
intended case where a Swift module shadows a Clang module without also
re-exporting it. Switch to "underlying", which was already in use in a
few places, and which better parallels "overlay".
No intended functionality change.
To distinguish between classes which have the same name (but are in different contexts).
Fixes a miscompile if classes with the same name are used from a different module.
SR-10634
rdar://problem/50538534
Previously 'isSystemModule()' returns true only if the module is:
- Standard library
- Clang module and that is `IsSystem`
- Swift overlay for clang `IsSystem` module
Now:
- Clang module and that is `IsSystem`; or
- Swift overlay for clang `IsSystem` module
- Swift module found in either of these directories:
- Runtime library directoris (including stdlib)
- Frameworks in `-Fsystem` directories
- Frameworks in `$SDKROOT/System/Library/Frameworks/` (Darwin)
- Frameworks in `$SDKROOT/Library/Frameworks/` (Darwin)
rdar://problem/50516314
Serialize the relationship between a property that has an attached delegate
and its backing variable, so deserialization can reestablish that link.
Fixes rdar://problem/50447022.
Dependency tracking for cached compiled modules (compiled from
swiftinterfaces) can lead to a high percentage of the module being
SDK-relative paths when -track-system-dependencies is on. Cut down on
this by storing directory names in a separate record that gets
referenced from each file dependency. (Since a lot of per-file
dependencies are header files in a common directory, this is a win.)
We can do something more clever in the future, but this is a
reasonable start for, say, the overlays.
rdar://problem/50449802
Fix a trio of issues involving mangling for opaque result types:
* Symbolic references to opaque type descriptors are not substitutions
* Mangle protocol extension contexts correctly
* Mangle generic arguments for opaque result types of generic functions
The (de-)serialization of generic parameter lists for opaque type
declarations is important for the last bullet, to ensure that the
mangling of generic arguments of opaque result types works across
module boundaries.
Fixes the rest of rdar://problem/50038754.
form SerializedModuleLoader into its own ModuleLoader class. (NFC-ish)
This gives better control over the order in which the various module
load mechanisms are applied.
When printing a swiftinterface, represent opaque result types using an attribute that refers to
the mangled name of the defining decl for the opaque type. To turn this back into a reference
to the right decl's implicit OpaqueTypeDecl, use type reconstruction. Since type reconstruction
doesn't normally concern itself with non-type decls, set up a lookup table in SourceFiles and
ModuleFiles to let us handle the mapping from mangled name to opaque type decl in type
reconstruction.
(Since we're invoking type reconstruction during type checking, when the module hasn't yet been
fully validated, we need to plumb a LazyResolver into the ASTBuilder in an unsightly way. Maybe
there's a better way to do this... Longer term, at least, this surface design gives space for
doing things more the right way--a more request-ified decl validator ought to be able to naturally
lazily service this request without the LazyResolver reference, and if type reconstruction in
the future learns how to reconstruct non-type decls, then the lookup tables can go away.)
Escapingness is a property of the type of a value, not a property of a function
parameter. Having it as a separate parameter flag just meant one more piece of
state that could get out of sync and cause weird problems.
Instead, always look at the noescape bit in a function type as the canonical
source of truth.
This does mean that '@escaping' is now printed in a few diagnostics where it was
not printed before; we can investigate these as separate issues, but it is
correct to print it there because the function types in question are, in fact,
escaping.
Fixes <https://bugs.swift.org/browse/SR-10256>, <rdar://problem/49522774>.
When a Swift module built with debug info imports a library without
debug info from a textual interface, the textual interface is
necessary to reconstruct types defined in the library's interface. By
recording the Swift interface files in DWARF dsymutil can collect them
and LLDB can find them.
rdar://problem/49751363
Previously, the ParseableInterfaceModuleLoader relied on the assumption
that, if it returned `errc::not_supported`, it would fall through the
search paths and then move on to the SerializedModuleLoader. This did
not anticipate the possibility of a valid .swiftinterface coming later
in the search paths, which can cause issues for the standard library
which is in the resource-dir and should always be loaded from there.
Instead, make the module loading explicitly short-circuit when seeing
`errc::not_supported`, and document it.
Also add some more logging throughout `discoverLoadableModule` so we can
more easily catch issues like this in the future.
Fixes rdar://49479386
