...so don't report a second "module missing" error from Swift itself.
We do still treat the Clang module failing to build as a fatal error.
<rdar://problem/16175035>
Swift SVN r18231
We're not mapping source locations over correctly yet, so the file name
where an error occurs gets shoved into the diagnostic text, but that's
fine for now.
This also silences the "module 'Blah' not found" error coming from the
importer whenever Swift itself can be responsible for importing the module.
Still to do: if we can't build a Clang module, we shouldn't report that
error and then say it can't be found.
<rdar://problem/14509389>
Swift SVN r18230
This allows "obj.description!" to work on iOS when 'obj' is an AnyObject,
even though 'description' is an implicit property created by the importer.
Swift SVN r18149
Otherwise, it can't find the appropriate ~= to use for synthesized NS_ENUM
RawRepresentable conformances, leading to bizarre errors about the
underlying type (usually Int) not being able to convert to NSObject.
<rdar://problem/16923405>
Swift SVN r18131
attributes and create implicit conversions for them.
Also, when generating Clang modules for import, set the
appropriate macro to make CoreFoundation actually apply
those attributes to its typedefs.
Also, give shared linkage to imported class method
definitions.
The net effect is that CFString now automatically
converts to NSString and vice-versa.
Depends on Clang r208756 in order to preserve attributes
applied to tag types in multiple typedef declarations.
Swift SVN r18069
This performs very conservative dependency generation for each compile task
within a full compilation. Any source file, swiftmodule, or Objective-C
header file that is /touched/ gets added to the dependencies list, which
is written out on a per-input basis at the end of compilation.
This does /not/ handle dependencies for the aggregated swiftmodule, swiftdoc,
generated header, or linked binary. This is just the minimum needed to get
Xcode to recognize what needs to be rebuilt when a header or Swift source
file changes. We can revisit this later.
This finishes <rdar://problem/14899639> for now.
Swift SVN r18045
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
