SourceManager expects that SourceLocations have the main FileID as parent, except for the predefines buffer.
Fixes assertion hit in a SourceKit test.
Swift SVN r17851
Previously, we were just using the base name, which resulted in massive
inefficiency when dealing with Clang (we basically had to check every
selector in the system to see if it had the same first selector piece).
I've hacked ConstraintSystem a bit to carry a map from UnresolvedDotExpr
to the ApplyExpr that consumes it, so that we can use the full DeclName
and look up methods by full selector.
Now that dynamic lookup is fast, re-enable it for the
Foundation_bridge.swift test. (r17520 actually provided most of the benefit.)
This does break selector lookup on AnyObject when doing selector splitting,
and slightly regresses diagnostics when you try to call a method on AnyObject
and forget a parameter name.
<rdar://problem/16808651>. Part of the Playground performance efforts.
Swift SVN r17524
This improves the -import-objc-header option to read decls from the header
as well. Any declaration that is not from a module will be considered to be
part of the "header module". Conversely, forward-declarations appearing in
the header will be resolved by looking through all modules responsible for
importing a header.
More of <rdar://problem/16702101>
Swift SVN r17492
When importing an Objective-C init method or factory method into an
initializer, if the first camelCase word of the first argument name
starts with "with", drop the "with". This means that
-initWithRed:green:blue:alpha:
will get imported into Swift as
init(red:green:blue:alpha:)
as will
+colorWithRed:green:blue:alpha:
This is <rdar://problem/16795899>, hidden behind the
-implicit-objc-with flag.
Swift SVN r17271
THIS IS NOT READY FOR USE YET.
The new plan for mixed-source non-framework targets is that the Swift
compiler will import an Objective-C header directly, and treat the decls
and imports in that header as explicitly visible to the entire target.
This means users don't have to modularize their headers before bringing
them into Swift.
This commit adds the option and introduces the "imported headers" module
as an implicit import for the source files being compiled. It also directs
the Clang importer to process the given header (using #import, so that it
won't somehow get included twice) and watches for any module imports that
occur as a result of reading that header.
Still to come: import of decls within the header (not within any module),
and proper serialization of cross-references to the header and its imports.
Part of <rdar://problem/16702101>
Swift SVN r17218
We're going to need the parser again later, and we probably shouldn't be
hoping Clang's -fsyntax-only mode lines up with what we need to do anyway.
Swift SVN r17124
Also, create the Clang module loader directly rather than indirecting through
a "get constructor" function. It's no longer a valid configuration to not
have a Clang importer.
Swift SVN r16862
The hardcoding of CPU settings in lib/Driver/Tools.cpp isn't at all ideal,
but it will let us limp along for now.
<rdar://problem/16641385>
Swift SVN r16861
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
"all" was leaving out submodules, which are not privately visible but are
publicly visible. "private-only" had a logic inversion.
This unfortunately introduces some non-determinism in trying to unique the
imports.
Swift SVN r16719
The clang TargetInfo for ARM64 defaults to aapcs unless darwinpcs is
specifically requested (which clang's driver does when compiling for
ARM64), so we end up with the wrong ABI.
I filed <rdar://problem/16687086> because it seems reasonable for
TargetInfo to default to darwinpcs when the target OS is known to be
isOSDarwin.
Swift SVN r16654
We started tracking statistics for these in r16529, but because we've
"always" done this for initializers, it's trivial to just implement
the splitting. As with initializers, we synthesize a named argument of
type '()' to capture the part of the first selector piece that follows
the class name.
Swift SVN r16530
For example, in an Objective-C class like this:
@interface NSFoo
+(instancetype)fooForReading;
@end
We don't import that class method as an initializer yet.
Swift SVN r16529
mystical workaround that hits our dogfooders.
Address this by adding '-fmodules-validate-system-headers' to the clang importer, which rebuilds the clang modules if system headers change.
By my unscientific testing I didn't see significant difference for compile time on the template Cocoa project beyond noise level, and it shouldn't
be significant on the project level because clang module importing happens on per-swift-target basis, not per-swift-file.
Swift SVN r16482
When an Objective-C class method follows the naming convention of a
factory method, i.e., its starting words match the ending words of the
class name, import it as a convenience initializer when it also:
- Returns instancetype (i.e., dynamic Self in Swift parlance)
- Has no NSError** parameters, which indicate the potential for failures
This is under a new flag (-enable-objc-factory-method-constructors)
because it is not generally functional. However, this is a step toward
<rdar://problem/16509024>.
Swift SVN r16479
This makes a number of changes to the selector-splitting
heuristics. Specifically:
- Eliminate last-word splitting, and with it the notion of
multi-words. We only split at prepositions now.
- Introduce the notion of "linking verbs" such as "will" or
"should"; when these show up, we refuse to split a selector, which
helps with delegates.
- Eliminate the special case for "get" and "set". It wasn't
helping.
Swift SVN r16265
In Objective-C, any method with no arguments can be used with dot syntax, as
can any method that takes one argument whose name starts with "set". This
commit adds a frontend-only flag -enable-objc-implicit-properties to look for
"setter-like" methods that match up with "getter-like" methods to import them
as Swift properties. By default, such methods are just considered unrelated
methods.
Part of <rdar://problem/16215476>
Swift SVN r16025
Seed the whitelist with the designated initializers for NSObject,
NSDocument, and UIDocument. We'll grow this list over time.
Fixes <rdar://problem/16521299>.
Swift SVN r16013
Regardless of the heuristic we choose when importing Objective-C
selectors into Swift method names, there will be poor cases. Allow us
to bake specific mappings into the compiler so we can address those
cases without having to modify the Objective-C headers.
Part of <rdar://problem/16341485>.
Swift SVN r15984
This makes sure that Clang uses the mangled class names for
Swift-defined classes. Should be last compiler-side piece of
<rdar://problem/15506580>.
Swift SVN r15977
Import a selector into a Swift method name, performing splitting at
that point. Use the resulting method name to determine the argument
names of the parameters, rather than trying to chop up the selector
again. There's more refactoring to do here.
This fixes a longstanding bug where the first argument of an
Objective-C method got the internal parameter name when it should
have gotten no name at all.
Swift SVN r15850
