Rather than require clients of lookupQualified() to resolve
their type declarations to nominal type declarations (and
separately cope with modules), have lookupQualified() accept
an array of TypeDecls and handle the resolution to nominal
type declarations (where it can look directly) and module
declarations, combining the results.
Switch a number of callers of the Type-based lookupQualified() over to
the newer (and preferred) declaration-based lookupQualified(). These are
the easy ones; NFC.
Make the core lookupQualified() API accept an array of TypeDecls in which
it should look, rather than looking into a Type. This is in preparation
for breaking more type-checker dependencies in the name lookup code.
I picked accessors that not only return the same result every time,
but also do no interesting validation work with possible side effects.
We have a lot more accessors that return the same result but also
force a bunch of things to be loaded or diagnostics to be emitted, and
I didn't want to change the behavior of any of those.
No intended functionality change; this is just supposed to be a small
optimization hint.
Many clients don't care about non-Decl DeclContexts, so there isn't any
need or reason to fully demux DeclContexts into precise DeclContextKinds.
This change improves the Swift.o optimized/no-assert build performance by
1.97% on Intel's Skylake processor on Linux.
When determining which declaration context should own a particular
protocol conformance that was not explicitly spelled out, prefer
"synthesized" contexts (i.e., which is always the nominal type itself)
for automatically-generated conformances (such as a raw-valued enum's
conformance to RawRepresentable) to conformances that are "implied" by
conformance to a more-refined protocol. Previously, we biased the
other way---but because conformances due to more-refined protocols can
be discovered later, we could get into a problem where two files
disagreed on which context would own the conformance---and neither
would emit the corresponding witness table.
Biasing toward "synthesized" contexts, which are always trivially
discoverable from the nominal type declaration itself, eliminates the
issue.
Fixes SR-6839 / rdar://problem/36911943.
Adding getAsGenericContext() cleans up some code, and improves the
Swift.swiftmodule build time by almost half a percent on LLVM
top-of-tree and with a simulated fix for LLVM PR35909.
DeclContexts as they exist today are "over aligned" when compared to
their natural alignment boundary and therefore they can easily cause
adjacent padding when dropped into the middle of objects via C++
inheritance, or when the clang importer prefaces Swift AST allocations
with a pointer to the corresponding clang AST node.
With this change, we move DeclContexts to the front of the memory layout
of AST nodes. This allows us to restore natural alignment, save memory,
and as a side effect: more easily avoid "over alignment" in the future
because DeclContexts now only need to directly track which AST node
hierarchy they're associated with, not specific AST nodes within each
hierarchy.
Finally, as a word of caution, after this change one can no longer
assume that AST nodes safely convert back and forth with "void*". For
example, WitnessTableEntry needed fixing with this change.
The empty sentinel in the lookup table caused recursion-breaking to bottom
out in slightly different order than the old eager code, making certain
order-sensitive tests fail.
The empty sentinel in the lookup table caused recursion-breaking to bottom
out in slightly different order than the old eager code, making certain
order-sensitive tests fail.
The AST verifier was causing deserialization of generic environments,
which slows things down considerably and affects our ability to test
for laziness in deserialization. Prevent it from doing so---and only
do the extra checkig if something else deserialized the generic
environment already.
... except there are some cases where it happens through means that
are harder to control (e.g., the AST walker for patterns) that need
more thought.
When performing a name lookup from inside of a protocol
or extension, skip directly to the source file context
when we are done visiting the protocol or extension.
Otherwise, if we have invalid code where the protocol
or extension is nested inside another type, we might
find a member whose type contains generic parameters
of the outer type; these parameters will not resolve,
since we do not model protocols or extensions nested
inside generic contexts (yet?).
This supercedes an earlier workaround for a similar
issue; the new workaround fixes more crashes.
This is needed to avoid crasher regressions with an
upcoming patch.
This is intended to have no functional effect, but there was a
minor change to a diagnostic in invalid code in the tests for the
unfinished ASTScope code; I hope I didn't break anything more
fundamental there.
When we deserialize a function that has a generic environment, set the
generic signature and a key to allow lazy creation of the generic
environment. Because most clients won't need the generic environment,
this lets us avoid creating generic environments.
Save two pointers of storage in IterableDeclContext (a base class of
nominal type and extension declarations) by storing the lazy member
loader + context data in an ASTContext side table. It also makes it
easier to add more lazy context information later on.
This method gets the GenericTypeDecl for a typealias, nominal type, or
extension thereof. While the result is typed as GenericTypeDecl, it's
not always generic, so rename it accordingly.
An audit of the callers illustrated that they should be using
different entrypoints anyway, so fix all of the callers and make this
function private.
DeclContext's nomenclature around "type contexts" is confusing,
because it essentially means "nominal type contexts", e.g.,
struct/class/enum/protocol and extensions thereof. This implies the
presence of a 'Self' type, the ability to have members, etc.
However, typealiases are also currently classified as "type
contexts", despite not having a reasonable 'Self' type, which breaks
in various places. Stop classifying typealiases as "type contexts".
First, ensure all ParamDecls that are synthesized from scratch are given
both a contextual type and an interface type.
For ParamDecls written in source, add a new recordParamType() method to
GenericTypeResolver. This calls setType() or setInterfaceType() as
appropriate.
Interestingly enough a handful of diagnostics in the test suite have
improved. I'm not sure why, but I'll take it.
The ParamDecl::createUnboundSelf() method is now only used in the parser,
and no longer sets the type of the self parameter to the unbound generic
type. This was wrong anyway, since the type was always being overwritten.
This allows us to remove DeclContext::getSelfTypeOfContext().
Also, ensure that FuncDecl::getBodyResultTypeLoc() always has an interface
type for synthesized declarations, eliminating a mapTypeOutOfContext()
call when computing the function interface type in configureInterfaceType().
Finally, clean up the logic for resolving the DynamicSelfType. We now
get the interface or contextual type of 'Self' via the resolver, instead
of always getting the contextual type and patching it up inside
configureInterfaceType().
There's a bit of a hack to deal with generic typealiases, but
overall this makes things more logical.
This is the last big refactoring before we can allow constrained
extensions to make generic parameters concrete. All that remains
is a small set of changes to SIL type lowering, and retooling
some diagnostics in Sema.
A GenericEnvironment stores the mapping between GenericTypeParamTypes
and context archetypes (or eventually, concrete types, once we allow
extensions to constrain a generic parameter to a concrete type).
The goals here are two-fold:
- Eliminate the GenericTypeParamDecl::getArchetype() method, and
always use mapTypeIntoContext() instead
- Replace SILFunction::ContextGenericParams with a GenericEnvironment
This patch adds the new data type as well as serializer and AST
verifier support. but nothing else uses it yet.
Note that GenericSignature::get() now asserts if there are no
generic parameters, instead of returning null. This requires a
few tweaks here and there.
Now that ConstraintSystem::openGeneric() is the only remaining
caller of this function, inline it in there and open-code the
logic.
Also, add a hack for opening nominal types contained inside
protocol types. This is invalid, but we should not crash, so
bind the type variable for the protocol 'Self' type to the
'Self' archetype, since it will not be equated with anything
otherwise.
There was a weird corner case with nested generic functions that
would fail in the SIL verifier with some nonsense about archetypes
out of context.
Fix this the "right" way, by re-working Sema function declaration
validation to assign generic signatures in a more principled way.
Previously, nested functions did not get an interface type unless
they themselves had generic parameters.
This was inconsistent with methods nested inside generic types,
which did get an interface type even if they themselves did not
have a generic parameter list.
There's some spill-over in SILGen from this change. Mostly it
makes things more consistent and fixes some corner cases.
If a function is public, and either @_transparent or @inline(__always),
we need to make its body available for inlining in other resilience
domains. The more general concept here is an 'inlineable' function;
once the precise behaviors we want are nailed down, the set of AST
attributes for exposing this will likely change.
At the SIL level, inlineable functions are marked with the [fragile]
attribute. The SIL serializer only serializes [fragile] functions
unless -sil-serialize-all is passed in.
This patch fixes two problems in this area by consolidating some
duplicated logic:
1) Property accesses in Sema did not check for @inline(__always)
functions, or functions nested inside inlineable functions.
This manifested as IRGen crashes if an inlineable function
accessed a property of a resilient type.
2) In SILGen, functions nested inside [fragile] functions were
properly [fragile], but @inline(__always) was not taken into
account. This manifested as SIL serializer crashes where a
[fragile] function could reference a non-public, non-[fragile]
function.
This change is part of the series for building the standard library
without -sil-serialize-all.
