Soft revert a09382c. It should now be safe to add this flag back as an optimization to specifically disable lazy member loading instead of all extension loading.
Push the flag back everywhere it was needed, but also push it into lookup for associated type members which will never appear in extensions.
Lazy loading checked if the ClangDecl was hidden, but loading all
members did not. Let's make loadAllMembers() behave like the lazy
path, and fix some of the mock SDKs in the test suite.
Allow two methods to be imported with the same selector, as long as they
have different Swift DeclNames. This is required for lazy mirrored protocol
member loading to work correctly, so that the same declarations are
imported regardless of name lookup order. The commit for the mirrored
protocol member change will have test cases that cover this behavior.
The Clang Importer allows for the creation of otherwise illegal Swift
ASTs because it does not run redeclaration checking or override
checking. These behaviors are also not a part of our test suite.
Correct the first issue by re-instating the old emergent behavior of
member loading occurring at all points in the class hierarchy before
a (lazy) lookup.
Correct the second issue by adding a regression test for a common
failure mode in the post-re-entrant-lookup Clang Importer.
We cannot stop accepting these cases, but a future compiler will warn
about them.
Attacks rdar://58493370
We would add all imported members to a per-nominal vector, and
then perform shadowing checks on the entire list, followed by
visiting each one to look for a matching member with the
right name.
We were spending a lot of time inside this function as a result.
Instead, change Impl.MembersForNominal to store a mapping from
names to lists of members having that name, changing this into
an O(1) lookup.
Fixes <rdar://problem/58363207>.
Push some state closer to where it's actually needed and remove helper functions that aren't actually all that helpful. Replace these with an assertion for the real invariant here.
Lazy member loading had an antagonistic relationship with the import-as-member facilities. The member tables were stored in a hash map that is keyed by serialized declaration context. While this was good for importing the entire member set of a given extension, it's in the complete wrong order for lazy member loading, which wants the same data keyed by base name.
Given that it is annoying to redo the globals-as-member tables to support one use case or the other, coupled with the fact that optimizing for one use-case automatically pessimizes the other, just take a page from rdar://18696086 and store the same information twice in two separate formats each optimized for the task at hand.
Preliminary benchmarks indicate that this leads to a 5% reduction in Clang-Imported entities which will drastically speed up most apps that use Dispatch and CoreGraphics.
We’re going to start serializing this for public types that have non-public-or-@usableFromInline initializers, so turn it into a request that we can query and cache it in the existing bit.
This serves as a bug fix and a nice cleanup. The old algorithm failed
to stop at the nearest override point and thereby introduced semantic
ambiguities on lookups for clashing overridden decls.
Resolves rdar://57916229
When deserializing a the (named) members of a class hierarchy, we
needn't walk all the way up the hierarchy, just into our superclass.
This will, in turn, walk to its superclass, etc. This is as opposed to
this work being repeated at each level of the recursive hierarchy.
Should be a small perf win over the last patch.
An unfortunate pessimization that is needed in order to properly build the member table to run override checking. Considering this was happening anyways thanks to re-entrant lookups, there shouldn't actually be a perf hit here.
The general problem with this approach is that the clang importer is part of the cache-fill for name lookup. This means that qualified lookups it runs will be re-entrant and result in validation-order-dependent behaviors.
The next commit will restore the expected ordering behavior here.
Prevents a cycle where a general access to all top level decls lead the
deserialization to call ClangImporter which triggered more
deserialization. It crashed the compiler in a complex case so only
limiting what is deserialized should be enough to fix this for now.
rdar://problem/57118844
These include memberwise initializers for pointer properties and enum
case constructors for pointer payloads. In both cases, the pointer is
being immediately escaped, so don't allow the user to pass a temporary
pointer value.
Christopher Rogers' (good) work in 49fd5acbb2 caught places where
the Swift compiler was allowing a @class to resolve to a Swift class
even if that class had a conflicting Objective-C name, or wasn't
intended to be exposed to Objective-C at all. Unfortunately, this
broke source compatibility in projects where people were relying on
this. Restore that functionality, but only as a fallback; matching the
Objective-C name is better than matching the Swift name.
rdar://problem/56681046
Previously we only did this for factory methods, but there's no reason
why we can't do it for regular init methods too, and doing so
simplifies the signature of SwiftDeclConverter::importConstructor.
Also remove some indirection through helper functions in ClangAdapter.
These were more useful back when Swift looked directly at API notes
instead of relying on Clang turning them into attributes; now they're
just an extra hop for no reason.
The code does naive lookup of Swift types using the type name, but sometimes the Swift type we're looking for only has that name in its @objc attribute. This change makes the compiler exclude certain Swift declarations from matching even if the Swift name is the same (namely, not being available in Obj-C or having a mismatched `@objc` name) and continue to find the correct declaration without using lookup by name.
Fixes SR-4827
This is an amalgam of simplifications to the way VarDecls are checked
and assigned interface types.
First, remove TypeCheckPattern's ability to assign the interface and
contextual types for a given var decl. Instead, replace it with the
notion of a "naming pattern". This is the pattern that semantically
binds a given VarDecl into scope, and whose type will be used to compute
the interface type. Note that not all VarDecls have a naming pattern
because they may not be canonical.
Second, remove VarDecl's separate contextual type member, and force the
contextual type to be computed the way it always was: by mapping the
interface type into the parent decl context.
Third, introduce a catch-all diagnostic to properly handle the change in
the way that circularity checking occurs. This is also motivated by
TypeCheckPattern not being principled about which parts of the AST it
chooses to invalidate, especially the parent pattern and naming patterns
for a given VarDecl. Once VarDecls are invalidated along with their
parent patterns, a large amount of this diagnostic churn can disappear.
Unfortunately, if this isn't here, we will fail to catch a number of
obviously circular cases and fail to emit a diagnostic.
Since getSpecifier() now kicks off a request instead of always
returning what was previously set, we can't pass a ParamSpecifier
to the ParamDecl constructor anymore. Instead, callers either
call setSpecifier() if the ParamDecl is synthesized, or they
rely on the request, which can compute the specifier in three
specific cases:
- Ordinary parsed parameters get their specifier from the TypeRepr.
- The 'self' parameter's specifier is based on the self access kind.
- Accessor parameters are either the 'newValue' parameter of a
setter, or a cloned subscript parameter.
For closure parameters with inferred types, we still end up
calling setSpecifier() twice, once to set the initial defalut
value and a second time when applying the solution in the
case that we inferred an 'inout' specifier. In practice this
should not be a big problem because expression type checking
walks the AST in a pre-determined order anyway.
By requestifying the raw value accessor and pushing the semantic check
into IRGen, we are now partially validating enums that are
synthesized by the clang importer and deserialization - something that
we were not doing before. The previous check would only skip
the auto-incrementer step when this was the case. We now also skip the
uniqueness check.
Resolves rdar://56037318
Structurally prevent a number of common anti-patterns involving generic
signatures by separating the interface into GenericSignature and the
implementation into GenericSignatureBase. In particular, this allows
the comparison operators to be deleted which forces callers to
canonicalize the signature or ask to compare pointers explicitly.
