of 'init' method family with Clang (it looks like 'init123' would count as init
method in Clang, but not in the initial implementation of selector splitting in
Swift).
Swift SVN r15189
The frontend option -split-objc-selectors splits the first part of an
Objective-C selector into both a function name and the first parameter
name at the last preposition. For example, this Objective-C method:
- (NSString *)stringByPaddingToLength:(NSUInteger)newLength withString:(NSString *)padString startingAtIndex:(NSUInteger)padIndex
is imported as
func stringByPadding toLength(newLength: Int) withString(padString: String) startingAtIndex(padIndex: Int) -> String
Swift SVN r15156
In a framework containing both Clang headers and a Swift module, the Swift
module gets picked up first, but then automatically imports (and re-exports)
the Clang module as well.
One interesting case here is that it's possible for the Clang side to add
categories to a class declared in Swift. In order to support this, the
Clang importer can now find extensions for Swift classes marked @objc.
(I couldn't think of a way to test this separately; the previous commit
was supposed to do that, but worked without this change.)
<rdar://problem/16295937>
Swift SVN r15084
This is the same as the previous commit, but for protocols. To do this I
had to modify the ObjC printer to include a SWIFT_PROTOCOL annotation like
the SWIFT_CLASS annotation already in use. This is probably a good thing
anyway.
Second half of <rdar://problem/16296027>
Swift SVN r14985
This is necessary to handle Swift code using API defined in Objective-C
that itself uses classes defined in Swift. Protocols coming next.
First half of <rdar://problem/16296027>
Swift SVN r14984
...so that the Clang module machinery will check that the generated pcm
is up-to-date.
We probably want this to be considered a system header in the long run,
but this is a quick fix for those working on the standard library.
<rdar://problem/16285900>
Swift SVN r14926
In Sema, give derived '==' definitions the module's DerivedFileUnit as their decl context instead of the more general Module, and give it a backreference to the nominal type for which it was derived.
In SILGen, visit the derived global decls associated with Clang-imported enums, and give them shared linkage. Part of fixing <rdar://problem/16264703>.
Swift SVN r14875
In these cases, disable the standard system include paths so we don't
accidentally pick up headers in /.
This is going to be used by the runtime team for low-level interfaces with
C and Objective-C in the standard library.
Swift SVN r14789
Make the name lookup interfaces all take DeclNames instead of identifiers, and update the lookup caches of the various file units to index their members by both compound name and simple name. Serialized modules are keyed by identifiers, so as a transitional hack, do simple name lookup then filter the results by compound name.
Swift SVN r14768
This will allow us to ship headers that are used by the standard library.
They will be treated as system headers.
<rdar://problem/16227202>
Swift SVN r14757
The former is an obvious fix; the latter is a speed optimization when using
the Debug REPL. Running the crashing code through -i will get nearly the
same effect with verification turned on.
Swift SVN r14468
This is hidden behind the frontend flag -enable-objc-optional. Use -Xfrontend
when invoking the Swift driver.
Part of <rdar://problem/15189135>
Swift SVN r14332
This is more in line with all other modules currently on our system.
If/when we get our final name for the language, we're at least now set
up to rename the library without /too/ much trouble. (This is mostly just
a lot of searching for "import swift", "swift.", "'swift'", and '"swift"'.
The compiler itself is pretty much just using STDLIB_NAME consistently now,
per r13758.)
<rdar://problem/15972383>
Swift SVN r14001
This is needed for the implicit conformances we synthesize. Remove a
hack from TypeCheckConstraints to find swift.~= now that it's available
using normal lookup.
<rdar://problem/15410928>
Swift SVN r13850
Also, disallow creating Modules and FileUnits on the stack. They must always
live as long as the ASTContext.
<rdar://problem/15596964>
Swift SVN r13671
This keeps us from having to deal with fat swiftmodules for now.
In the long run we're hoping to solve this problem with build configurations,
so that a single module file can support multiple architectures.
(See <rdar://problem/15056323>)
<rdar://problem/15204953>
Swift SVN r13135
Hardcoding a path to a particular SDK is definitely the wrong thing to do.
Let's see how far we can get without setting a default SDK.
See discussion in <rdar://problem/14395800>
Swift SVN r12414
This can happen when importing a decl causes a new Swift module to be loaded
(because it uses one of our bridged types), which then brings in a new Clang
module. In this case we have no choice but to throw out the existing cache
and start over. We do keep a map of everything we've imported already, though,
so at least we don't have to do that part again.
This appears to make r12309 unnecessary for correctness, but it probably still
makes performance more consistent.
<rdar://problem/15785883>
Swift SVN r12336
Clang's LookupVisibleDecls is implemented by iterating over the map of lookups,
which clearly isn't deterministic. This *shouldn't* be a problem, but it
seems our importer has non-determinism based on the order it sees decls.
For now, at least, let's make this deterministic up front so that we don't get
weird results from :print_module.
See <rdar://problem/15785883> and <rdar://problem/15799697>.
Swift SVN r12309
Rather than append the "Proto" suffix to all imported Objective-C
protocols, which can be confusing, whitelist those protocols that we
do have to rename. Only NSObject falls into this category so far.
Fixes <rdar://problem/15741699>.
Swift SVN r11856
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
Not only this creates less ASTs, but this makes the resulting AST correct (it
is invalid to have a struct and a typealias with the same name). But the
primary motivation is AST pretty-printing: we don't want to print those extra
useless typealiases.
Swift SVN r11289
"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
