Fixes rdar://problem/14776565 (AnyObject lookup for Objective-C
properties with custom getters) and rdar://problem/17184411 (allowing
__attribute__((swift_name("foo"))) to work on anything).
We decided not to support "implicit" properties, where we import
getter/setter pairs as properties. Rather, we only import a property
when there is an explicit "@property" in Objective-C. Remove the flag
and supporting code for implicit properties.
Most of this is in updating the standard library, SDK overlays, and
piles of test cases to use the new names. No surprises here, although
this shows us some potential heuristic tweaks.
There is one substantive compiler change that needs to be factored out
involving synthesizing calls to copyWithZone()/copy(zone:). Aside from
that, there are four failing tests:
Swift :: ClangModules/objc_parse.swift
Swift :: Interpreter/SDK/Foundation_test.swift
Swift :: Interpreter/SDK/archiving_generic_swift_class.swift
Swift :: Interpreter/SDK/objc_currying.swift
due to two independent remaining compiler bugs:
* We're not getting partial ordering between NSCoder's
encode(AnyObject, forKey: String) and NSKeyedArchiver's version of
that method, and
* Dynamic lookup (into AnyObject) doesn't know how to find the new
names. We need the Swift name lookup tables enabled to address this.
When we parse a bridging header, start building a mapping from Swift
names (both base names and full names) to the Clang declarations that
have those names in particular Clang contexts. For now, just provide
the ability to build the table (barely) and dump it out; we'll grow
it's contents in time.
My temporary hackery around inferring default arguments from imported
APIs was too horrible. Make it slightly more sane by:
1) Actually marking these as default arguments in the type system,
rather than doing everything outside of the type system. This is a
step closer to what we would really do, if we go in this
direction. Put it behind the new -frontend flag
-enable-infer-default-arguments.
2) Only inferring a default argument from option sets and from
explicitly "nullable" parameters, as stated in the (Objective-)C API
or API notes. This eliminates a pile of spurious, non-sensical "=
nil"'s in the resulting output.
Note that there is one ugly tweak to the overloading rules to prefer
declarations with fewer defaulted arguments. This is a bad
implementation of what is probably a reasonable rule (prefer to bind
fewer default arguments), which intentionally only kicks in when we're
dealing with imported APIs that have default arguments.
Swift SVN r32078
The -enable-omit-needless-words option attempts to omit needless words
from method names imported from Clang. Broadly speaking, a word is
needless if it merely restates the type of the corresponding parameter,
using reverse camel-case matching of the type name to the
function/parameter name. The word "With" is also considered needless
if whether follows it is needless, e.g.,
func copyWithZone(zone: NSZone)
gets reduced to
func copy(zone: NSZone)
because "Zone" merely restates type information and the remaining,
trailing "With" is also needless.
There are some special type naming rules for builtin Objective-C types,
e.g.,
id -> "Object"
SEL -> "Selector"
Block pointer types -> "Block"
as well as some very-Cocoa-specific matching rules, e.g., the type
"IndexSet" matches the name "Indexes" or "Indices".
Expect a lot of churn with these heuristics; this is part of
rdar://problem/22232287.
Swift SVN r31178
This should have no functionality change, but is supposed to keep us from
accidentally relying on the "full" Clang importer when in a backend job.
I tested it by archiving a little iOS app from a developer.
Unfortunately, part of the motivation here was that we'd get error messages when
we pass something Clang doesn't like, and that doesn't seem to be happening.
rdar://problem/21389553
Swift SVN r30407
Previously we hardcoded a few important default CPUs, ABIs, and features into
Swift's driver, duplicating work in Clang. Now that we're using Clang's
driver to create the Clang "sub-compiler", we can delegate this work to Clang.
As part of this, I've dropped the options for -target-abi (which was a
frontend-only option anyway) and -target-feature (which was a hidden driver
option and is a frontend-only option in /Clang/). We can revisit this later
if it becomes interesting. I left in -target-cpu, which is now mapped
directly to Clang's -mcpu=.
Swift SVN r22449
This can be used by SourceKit's interface printer to display modules with
forward declarations of classes in dependent modules, e.g. ObjectiveC
forward-declaring Foundation's NSString for use in NSObject. We can consider
doing something similar for C tag types (structs and enums).
Part of rdar://problem/18273845
Swift SVN r21828
In this mode, use nullability information on the result type of the
initializer or factory method to determine failability of the
initializer. This is behind the flag
-enable-objc-failable-initializers until we have the SILGen support in
place.
Swift SVN r21341
Add the ability to store optionality of the ObjC method parameters and return
type in a sidecar. This hardcoded info is then used to import Objective C
object pointer types as either optional or none, instead of implicitly
unwrapped optionals.
The feature is enabled with -import-with-tighter-objc-types=true.
Swift SVN r19048
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
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
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
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
Added a new ClangImporterOptions class which wraps the ModuleCachePath and ExtraArgs for the Clang importer.
Added a new ParseClangImporterArgs static function which fills in the passed-in ClangImporterOptions.
Updated CompilerInvocation and CompilerInvocation::parseArgs() to use ClangImporterOptions and ParseClangImporterArgs, respectively.
Swift SVN r11180
