This is functional for arbitrary Objective-C properties and methods
(the subject of rdar://problem/22214302), as well as for changing the
argument labels of C functions. However, it does not work when the
name of a global is changed because name lookup initiated from
Swift goes through the Swift lookup table. Fixes
rdar://problem/22214302 but is only a step toward
rdar://problem/17184411.
Swift SVN r32670
...including structs and struct fields, enums and enum cases, typedefs,
protocols, classes, and properties.
The main problem is that this /doesn't/ handle top-level /lookup/, so you
can't actually find any of these renamed types. This is fixed in the next
commit.
This does not handle methods, subscripts, or initializers.
Part of rdar://problem/20070465
Swift SVN r29427
This reverts r25401. After reviewing the issues this was intended to solve,
and then talking to Dave, I've decided that this doesn't actually solve
enough of the problems we wanted it to, and it creates added complexity,
so I'm taking it back out.
Originally rdar://problem/19667625.
Swift SVN r25489
This pattern isn't too uncommon:
typedef CF_ENUM(CFIndex, CFFoo) {
CFFooBar
};
typedef NS_ENUM(NSInteger, NSFoo) {
NSFooBar = CFFooBar
};
NSFoo and CFFoo are distinct types, but sometimes you need to convert from
one to the other. Today the only way to do to that is via rawValue, which
is especially unpleasant if the raw types don't match.
This commit introduces a new converting initializer for NSFoo:
init!(_ value: CFFoo) {
self.init(rawValue: RawType(value.rawValue))
}
It's failable by necessity because init(rawValue:) is failable for proper
enums. In practice an audit of our public headers found zero cases where
there are "more" cases in CFFoo than in NSFoo, i.e. cases where the
conversion would fail.
This also applies to option sets and opaque enums, but those use a
non-failable initializer because there's no way to check validity.
rdar://problem/19667625
Swift SVN r25401
In particular, the fake "<module-includes>" buffers all have that same name.
Use the buffer itself to provide identity. (We are already deliberately
keeping the buffers alive via their source managers.)
rdar://problem/19716081
Swift SVN r25200
The ClangDiagnosticConsumer forwards diagnostics from Clang's diagnostic machinery
to Swift's. It deliberately filters out things that happen in our top-level dummy
buffer (usually trivial things like "module imported here"). Unfortunately, it was
doing so by checking against the current SourceManager's "main file". When building
Clang modules (compiling PCM files), we're dealing with a new SourceManager, whose
main file is the module map file.
Instead, just check against the (very unlikely) name of our dummy input file,
like we do for imported headers.
rdar://problem/18867749
Swift SVN r23121
i.e. don't look for attributes on an @class somewhere.
Also do this for tag decls, whose attributes propagate forwards until there's
a definition.
<rdar://problem/17986861>
Swift SVN r21223
Background: if a Clang module /only/ imports submodules from another module,
we would lose all re-exports from that other module, because we're treating
all decls as part of the top-level module. This actually shows up with UIKit
and QuartzCore due to some weirdness in how the QuartzCore module is set up
(see <rdar://problem/17888079>), resulting in 'CALayer' not being visible
with just 'import UIKit'.
Workaround (this patch): treat Clang imports just like Swift imports: if the
submodule is referenced, so is the top-level module. This isn't great, but
it's not really any more awful than the rest of our Clang modules story.
<rdar://problem/17607060>
Swift SVN r20920
.../if/ the protocol and the class are from the same top-level Clang module.
If not, the protocol is /not/ renamed, and users will have to disambiguate
with module qualification.
This kills our hardcoded "RenamedProtocols" list; it turns out this pattern
is more common than we thought /and/ leads to cross-referencing issues.
<rdar://problem/16206627>
Swift SVN r18809
In Swift, a type and a value (such as a function) will never have the same
name, but we import C tag types (structs, unions, and enums) into the same
namespace as values, which can lead to ambiguity. If the user has managed
to make clear which one they want in source code, though, we should preserve
that information during serialization.
<rdar://problem/16979415>
Swift SVN r18536
Previously, the getter and setter for a property could disagree on what the
"type of the property" was: Unmanaged<CFType> vs. CFType, or COpaquePointer
vs. CMutableVoidPointer. Now, we treat property accessors as distinct from
normal methods when importing their parameter and result types, and have
those types follow the same rules as they would for the property itself.
This will need a bit of cleanup work once we're importing implicit properties
everywhere, but this handles the crashes and unfortunate limitations we were
seeing for WWDC.
<rdar://problem/16544938>
Swift SVN r17987
Swift sometimes has a different notion of visibility, even for Clang modules.
In particular, this was causing the C version of NSUTF8StringEncoding
(from Foundation) to show up in AppKit, bypassing the Swift version in the
overlay.
We still want to search for redeclarations of functions, typedefs, and globals,
since these are often repeated in multiple modules without harm. The decl will
still have a "home" module, but this should allow them to be found by lookup.
<rdar://problem/16396994> and possibly <rdar://problem/14665250>
Swift SVN r16762
...and teach the type-checker to prefer variables to functions.
This matters in Objective-C, where you may have these two members:
@property NSURL *URL;
- (void)URL:(NSURL *)url resourceDidFailLoadingWithReason:(NSString *)reason;
This doesn't happen often, but we should do the right thing when it does.
We still won't import a property named 'foo' if there is already a method
'-foo' that takes no arguments.
<rdar://problem/16383845>
Swift SVN r15963
In Objective-C, all instance methods on a root class are also available as
class methods (because all class objects in Objective-C are instances of the
root class). However, we were incorrectly introducing class methods that
returned 'Self' (instead of 'Self.Type') for every instance method with a
related result type. Returning 'Self.Type' exposes a new type checker bug
<rdar://problem/16414206>, but in practice we don't have much reason to do
this anyway. For now, just don't try to mirror instancetype-returning methods
as class methods.
Swift SVN r15435
We're still synthesizing external definitions too eagerly, and things
getting pulled in only through submodules aren't getting properly autolinked.
(That is, AppKit imports <QuartzCore/CIImage.h> but doesn't think that
QuartzCore is visible, because it isn't.)
The first right answer is to detect that a part of QuartzCore is visible even
though the whole thing isn't. The second right answer is to properly handle
Clang submodules as real modules---there are a lot of rough edges there.
<rdar://problem/13140302>. The third right answer is that we shouldn't even
emit references to these symbols until the /user/ needs them.
And what I'm doing now is just to attempt to link to every module that we've
synthesized thunks for.
<rdar://problem/15754311>
Swift SVN r12031
Although Cocoa.framework re-exports AppKit, Foundation, and CoreData, an
arbitrary library does not re-export most of its imports. Normally this
would be fine, but the Clang importer can pull in types too eagerly and
then generate thunks and wrappers for things we don't care about. At least
for now, return to the behavior of autolinking /anything/ that gets visibly
imported.
<rdar://problem/15705923>
Swift SVN r11844
"import Cocoa" exposes the Swift adapter for Foundation, so we need to make
sure to link against both Cocoa.framework and libswiftFoundation.dylib.
We don't need to link against CoreData.framework, though; that's taken care
of by Cocoa.framework.
Swift SVN r11149
The hack was that __attribute__((iboutletcollection(NSView))) can be
specified on a collection property to provide its value type, and the
ClangImporter library co-opted that as a way to import NSArray properties
as NSTypedArray<NSView> (or whatever), a layout-compatible Swift struct
type that provided a typed (runtime-checked) view of an NSArray. The
implementation of NSTypedArray was never completed, however; none of
our sample code is actually using it; and it turns out to be problematic
for some instances of lazy type checking (because NSTypedArray is defined
in Swift). Remove it; we'll revisit this later.
Swift SVN r8639
This was accidentally causing a main module named "macros.swift" to be
treated as an overlay module for the Clang header "macros.h", and the
"overlay" was not re-exporting the Clang module.
Swift SVN r7782
This currently only works with Clang modules, since there's no way to specify
requirements for a Swift module.
Also, update some tests with a fake Foundation module to make sure they pick
up the fake Foundation adapter instead of the real one.
Swift SVN r7490
We can't IRGen the getter and setter thunks, and we don't want to import
the getter and setter methods individually because that's not
source-compatible with properties in Swift. Support for importing
protocol properties properly is tracked in <rdar://problem/12993073>.
Swift SVN r3735
We want to make sure that a global lookup always finds the Swift module
first. Moreover, we should never be loading two modules with the same name
into the same TU /unless/ they are (a) identical or (b) a Swift / C pair.
Swift SVN r3723
This allows us to add additional module import paths besides those provided
in the sysroot. This is necessary for the demo (so we can import our custom
ScriptingBridge header file) and will probably be needed in some form in the
long run to support mixed Swift/Objective-C projects.
Swift SVN r3721
