attribute or appear in a whitelist.
The initial whitelist is based on an audit I performed of our current
public SDKs. If there are CF types which appear only in our internal
SDKs, and somebody urgently needs to use them from Swift, they can
adopt the bridging attributes. The goal is to eventually eliminate
the whitelist and rely solely on bridging attributes anyway.
Sadly, CoreCooling was not included in my SDK audit and must be
explicitly annotated. :(
I've left the main database organized by framework, but I wanted
a quasi-lexicographically sorted version to permit efficient lookup.
We generate that copy automatically with gyb. I ended up having
to tweak handle_gyb_sources to allow it to drop the result in
CMAKE_CURRENT_BINARY_DIR instead of CMAKE_CURRENT_BINARY_DIR/{4,8}
if an architecture is not provided. I think this is abstractly
reasonable for generated includes, which have independent ability
to detect the target word size. But just between you and me,
I did it because I couldn't figure out how to add
"-I${CMAKE_CURRENT_BINARY_DIR/{4,8}" as a compile flag;
the obvious thing didn't work. Anyway, I'd appreciate it if
someone double-checked my cmake hackery here.
Swift SVN r24850
Previously we'd try to put the same method into the list of members multiple
times--once for each redeclaration in the @interface. This led to an
assertion failure.
Checking the canonical decl isn't super cheap, but the ObjCMethodDecl
redeclaration infrastructure seems to be fairly broken. We can revisit this
later.
There's also a test for what happens when categories get involved. I'm not
convinced this is correct behavior, either, and will file an additional bug
to look into that at some point.
rdar://problem/19039485
Swift SVN r24129
This completes <rdar://problem/17024498>, except that we don't yet do
anything with 'deprecated' or 'obsoleted'. The former is covered by
<rdar://problem/17406050>, and I filed <rdar://problem/17873422> for the
latter.
Swift SVN r20845
Nearly all of them come from some annotation written explicitly in the
Objective-C header, and all of them should be shown in the generated
interface for an imported module.
Part of <rdar://problem/17024498>
Swift SVN r20841
...and 'assign' and 'unsafe_unretained' as 'unowned(unsafe)', if the
property is a class type.
This isn't important for the compiler, but it is documentation for users
when they look at the generated interface for an Objective-C module.
Note that this actually produces a decl users can't yet write:
unowned(unsafe) var foo: UIView!
That's <rdar://problem/17277899> unowned pointers can't be optional.
<rdar://problem/17245555>
Swift SVN r20433
Because we don't want FooModule.#^A^# to show completion results for other
clang modules, global completion cache was replaced with a per-module cache.
Swift SVN r6951
