Objective-C subscripts don't have special declarations like
properties; they're just specially-named methods (or method pairs),
and we have to make an independent SubscriptDecl in Swift. This means
that when a subclass wants to make a subscript settable, they just add
the appropriately-named setter method.
Swift handled this by detecting when the getter and setter weren't
declared in the same type, and assuming this meant it was a subclass
adding a setter. Unfortunately, the same condition /also/ picked up
the case where the getter (and only the getter) is /redeclared/ in a
subclass (perhaps to add an attribute), and the new subscript was
getting added to the base class instead of the subclass.
The fix relies on the fact that the original decl we provide is what
we use to look up the other accessor. If the getter and setter are in
different types, whichever one we started with must be the
more-derived one. So the final change is just "did we start with the
setter?" rather than "is there a setter at all?".
I'm not sure why this is only just now causing problems, given that we
seem to have been getting this wrong for years, but it definitely
/was/ wrong and now it's not.
rdar://problem/36033356
When loading the named members for a given name, we want to load all
of the members with that base name... not only the ones that match the
full name, because the lookup table is indexed by base name and
filtering too early drops candidates.
Fixes rdar://problem/36085994.
Some functions and types are hidden behind feature flags.
_GNU_SOURCE exposes the most symbols and methods in glibc
and musl. Currently only turning it on for the Fuchsia triple.
This works a around search path problems caused by a module existing
in both the build/install directory and the source directory.
<rdar://problem/35714074>
Rather than being smart about this, just record an import failure when
we start importing a particular macro and update it at the end. Also
add a PrettyStackTrace to make this a little easier to track down in
the future.
The old logic for importing macros that just aliased other macros
managed to handle this in a clever way, but that was never tested for
the newer logic that evaluates expressions (fa834e2f80). Macro
importing in general probably deserves some cleanup, but meanwhile we
should make sure not to crash!
rdar://problem/34986930
(and vice versa)
Inadvertant fallout from 7725e38d96, which concerned accidental ambiguity
when mirroring protocol methods onto an implementing class.
https://bugs.swift.org/browse/SR-5959
Rather than storing contextual types in the type witnesses and associated
conformances of NormalProtocolConformance, store only interface types.
@huonw did most of the work here, and @DougGregor patched things up to
complete the change.
These kinds of synthesized declarations no longer need to go
through the constraint solver, since they have simple enough
bodies that we can construct type checked AST directly:
- rawValue getter and init(rawValue:)
- memberwise struct initializer
- zero struct initializer
Swift's ASTContext contained all of the logic to find the complete list
of properties for an Objective-C class, which is used by the Clang importer
to influence the mapping of Objective-C names into Swift. Swift's
ASTContext also included a *cache* for this information, indexed by
the Clang `ObjCInterfaceDecl *`. However, this cache was getting
populated/queried from the Clang importer's name importer, such that
the keys would be Clang declarations used to build modules and then
deallocated. If that memory eventually gets reused for a different
`ObjCInterfaceDecl *`, we would get incorrect/stale all-properties
information.
Almost Surely fixes rdar://problem/35347167, which is a
nondeterministic failure where UIView's `addGestureRecognizer(_:)` gets
occasionally imported as `add(_:)`.
This allows objc interop to be tested on non-darwin platforms. The iOS
runtime is used because the abi is the same as the macOS abi, but without
fragility concerns.
Select the language for the clang importer based on the
`-enable-objc-interop` flag rather than target. This paves the road to
enabling ObjC tests on non-Darwin targets as well as building on Darwin
without ObjC interop.
