An upstream clang changed ASTSourceDescriptor to not have a const
Module pointer. const_cast here to make this agree.
(cherry picked from commit a49bceeedf)
Start fixing SR-12526: `@derivative` attribute cross-module deserialization
crash. Remove original `AbstractFunctionDecl *` from `DerivativeAttr` and store
`DeclID` instead, mimicking `DynamicReplacementAttr`.
Type erasure requires a circular construction by its very nature:
@_typeEraser(AnyProto)
protocol Proto { /**/ }
public struct AnyProto : Proto {}
If we eagerly resolve AnyProto, the chain of resolution steps that
deserialization must make goes a little something like this:
Lookup(Proto)
-> Deserialize(@_typeEraser(AnyProto))
-> Lookup(AnyProto)
-> DeserializeInheritedStuff(AnyProto)
-> Lookup(Proto)
This cycle could be broken if the order of incremental inputs was
such that we had already cached the lookup of Proto.
Resolve this cycle in any case by suspending the deserialization of the
type eraser until the point it's demanded by adding
ResolveTypeEraserTypeRequest.
rdar://61270195
This imports const members of C++ structs/classes stored properties with
an inaccessible setter.
Note that in C++ there are ways to change the values of const members,
so we don't use `WriteImplKind::Immutable` storage.
Resolves: [SR-12463](https://bugs.swift.org/browse/SR-12463)
* Don't import C++ class members that are protected or private.
We omit protected members in addition to private members because Swift
structs can't inherit from C++ classes, so there's effectively no way to
access them.
* Check access specifiers centrally in importDeclImpl().
* Fix macOS build by using <stddef.h> instead of <cstddef>.
Apparently, the macOS toolchain doesn't provide <cstddef>.
<stddef.h> is used in test/Inputs/clang-importer-sdk/usr/include/macros.h,
so I'm assuming it will be OK. (I don't unfortunately have a macOS
machine to test on.)
* Add comment explaining why we skip private and protected C++ class
members.
Non-identifier names aren't currently an issue, but it will become one
when we add more support for C++, e.g. for C++ constructors (which I
plan to tackle soon).
When we found Objective-C methods via selector lookup, we would skip the
“should we even try to import this?” check. If the Swift-name-as-derived-
from-Objective-C is different from the actual Swift name, we might try to
(redundantly) import something from the generated Objective-C header,
which can lead to crashes. The specific method causing problems was defined
like this in Swift:
@objc public class func using(index: AnyObject) -> AnyObject? { return nil }
which produced an Objective-C method like this:
+ (id _Nullable)usingIndex:(id _Nonnull)index;
The Swift name derived from the Objective-C method is `usingIndex(_:)`, which
of course does not match `using(index:)`, meaning that we think these two
methods are different (they aren’t).
The safe fix is to check whether we should import a given Objective-C method
declaration along the found-via-Objective-C-selector path, like we do with
normal name lookup. A longer term fix is to emit swift_name attributes for
such methods.
Fixes the fiendish Clang importer crash in rdar://problem/60046206.
Recent clang side change merges ObjCCategoryDecl with the same name. All re-declarations
of a category points to the first category as the canonical one. This patch keeps these
non-canonical redeclarations as separate extensions in Swift.
rdar://problem/59744309
Because all metaclasses ultimately inherit from NSObject, instance
members of NSObject are also visible as static members of NSObject.
If the instance member is a property, we import the getter as an
ordinary static method, and not a static property.
The lazy loading path normally checks for the presence of alternate
decls with the same name, but it was failing to do this check if the
imported decl was a property and the alternate decl was attached to
the accessor and not the property itself.
This wasn't a problem until recently, because we weren't lazy loading
members of NSObject itself, since it had protocol conformances; now
that we are, this problem was exposed.
Fixes <rdar://problem/59170514>.
As part of this, we have to change the type export rules to
prevent `@convention(c)` function types from being used in
exported interfaces if they aren't serializable. This is a
more conservative version of the original rule I had, which
was to import such function-pointer types as opaque pointers.
That rule would've completely prevented importing function-pointer
types defined in bridging headers and so simply doesn't work,
so we're left trying to catch the unsupportable cases
retroactively. This has the unfortunate consequence that we
can't necessarily serialize the internal state of the compiler,
but that was already true due to normal type uses of aggregate
types from bridging headers; if we can teach the compiler to
reliably serialize such types, we should be able to use the
same mechanisms for function types.
This PR doesn't flip the switch to use Clang function types
by default, so many of the clang-function-type-serialization
FIXMEs are still in place.
This comes up when an imported error enum has duplicate cases.
The FooError.Code enum has an alias for the duplicate case, and
the wrapper type FooError defines aliases for every member of
FooError.Code.
The implementation of importEnumCaseAlias() assumed that 'original'
was an EnumElementDecl, and built AST accordingly; however if it
is a 'VarDecl', we have to build a MemberRefExpr instead.
This regression was introduced in https://github.com/apple/swift/pull/25009.
Fixes <rdar://problem/58552618>.
Add an algorithm to go search the override tables *and* the existing
loaded members of a class for a redeclaration point. The idea is that
both mirrored protocol members and categories offer a way to convince
the Clang Importer to import a property twice. We support a limited form
of this multiple-imports behavior today by allowing the redeclared
property to refine a readonly property into a readwrite property.
To maintain both the refinement behavior and to disambiguate any
remaining cases of ambiguity caused by extensions, attempt to identify
a redeclaration point if we can't identify an override point. Then,
decline to import the redeclared member if we're successful.
Note that the algorithm as presented is subject to import ordering. That
is, if a framework declares both an overlay and a clang module unit, if
the overlay is not loaded or members from the overlay are not installed
in the class by the time we see the declaration we may fail to identify
an redeclaration point.
The regression tests are for rdar://59044692, rdar://59075988, and
rdar://59125907.
Let's try calling ObjCInterface::lookupMethod() instead. This also
eliminates an order dependency between selector conflict checking
and protocol member mirroring, which fixes a diagnostics regression
once lazy loading is enabled for mirrored protocol members.
Once lazy loading supports mirrored protocol members, we can end up
calling importSubscript() for a setter method before we've mirrored
the getter. In this case, we call findCounterpart() with the setter,
which finds the imported getter from the ProtocolDecl itself.
Stop processing the potential subscript in this case, since when we
later mirror the protocol member, we'll go and build it again.
This should be NFC without the next change I'm working on.
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.
