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
Previously, we were using the context where the initializer was declared in Objective-C, rather than where it was being imported. This meant that we wouldn't treat an inherited designated initializer as a designated initializer if (for example) the designated-initializer marking came from our internal table of DIs. Fixes <rdar://problem/16838515>.
Swift SVN r17968
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
Note that this is still under -objc-bridge-dictionary, but otherwise
this should be all of the functionality needed for
<rdar://problem/16870626>.
Swift SVN r17848
Eliminate the duplicate half-broken bridging logic in emitClassConstructorAllocator by referencing foreign initializers through their foreign-to-native thunks, which SILGen knows how to emit already. Do the same thing for factory initializers by suppressing their normal allocating initializer codegen and just referencing the usual foreign-to-native thunk for them. This fixes <rdar://problem/16853205> because we get the ownership thunking right now.
Swift SVN r17840
Previously 'NSError**' was imported directly as
ObjCMutablePointer<NSError?>, which is verbose and quite ugly
in the synthesized interfaces and overrides. This remapping
is semantically equivalent by syntactically prettier.
This name needs to go through API review.
The test uses the actual SDK; the clang-importer-sdk didn't work
because the dump of the Foundation module only shows the pieces
from the Swift files, and the Objective-C pieces are just shown
as re-exported modules. Testing the actual SDK provides good
fidelity anyway.
Swift SVN r17707
corresponding getter method is audited.
There are a host of other potential consistency problems
here, but this should fix a particular egregious one
that was preventing use of NSColor's CGColor property.
rdar://16846555
Swift SVN r17667
Rather than force conformances to Equatable to be added to all imported enumeration types outright, change them back to being lazily added. We can then handle situations where new overloads of '==' are introduced during constraint generation by re-writing the relevant overload disjunction constraint to include the newly forced declarations as bind options.
Swift SVN r17557
- the type of a const global variable
- the type of a parameter, always
- the return type of a function that has been audited
or has an explicit retained/not-retained attribute
- the return type of an ObjC method that has an explicit
retain/not-retained/inner-pointer attribute
Additionally, choose the correct conventions for all
these cases during SIL type lowering.
All this importing logic is still only enabled under
-Xfrontend -import-cf-types.
Swift SVN r17543
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
We can enter here without an importing scope if we become more lazy, as can happen when <rdar://problem/16807886> is fixed. Add a regression test that fails when that patch is attached (but not yet on ToT).
Swift SVN r17513
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
Also, look through one layer of parentheses in general for macros, rather
than special-casing it for each token count.
<rdar://problem/16198517>
Swift SVN r17460
This routes around temporary SDK discrepancies.
This change revealed some subtle issues with adding implicit property
definitions. A big challenge here is that 'description' is defined
in NSObject's protocol, so the implicit property needed to be
generated in all classes that conformed to the protocol. To make
things more complicated, some classes define 'description' themselves,
so we needed to take care to not generate the same implicit property
twice.
This change reveals a potential bug in the type checker. This now
crashes:
func bar(x: String) {
print(x)
}
func foo(x : AnyObject) {
print(x.description)
}
but this does not:
func bar(x: String) {
print(x)
}
func foo(x : NSObject) {
print(x.description)
}
This is due to the fact there is a class method "description()" and
a instance property "description" in the lookup on AnyObject.
Swift SVN r17454
This basically just means "it's a CF class" for now,
but you could imagine applying this to all sorts of
class-like types from peer runtimes that we can't
support all possible language features for.
There are quite a few language features that require
fairly deep object-model integration to implement,
like subclassing and adding polymorphic methods.
Some of those features, like final classes, are useful
to generally support as attributes, but most of
them aren't. At least in the short term, it makes
sense to have a big hammer we can hit things with.
Swift SVN r17428
Subscript declarations were still encoding the names of index
variables in the subscript type, which unintentionally made them
keyword arguments. Bring subscript declarations into the modern day,
using compound names to encode the subscript argument names, which
provides consistency for the keyword-argument world
<rdar://problem/14462349>. Note that arguments in subscripts default
to not being keyword arguments, which seems like the right default.
We now get keyword arguments for subscripts, so one can overload
subscripts on the names of the indices, and distinguish at the call
site. Under -strict-keyword-arguments, we require strictness here as well.
The IRGen/IDE/SILGen test updates are because the mangling of common
subscripts changed from accidentally having keyword arguments to not
having keyword arguments.
Swift SVN r17393
va_list on i386 and arm64 is a pointer. On armv7, it's a struct that
/contains/ a pointer. But on x86_64, it's an array of one struct element,
which means it decays to a pointer as an argument but not as a variable or
struct field.
This patch:
- Looks for a decayed pointer argument that represents an x86_64 va_list.
- Validates that the va_list on other platforms is at least pointer-sized.
- Uses the decayed (pointer) type when getting the Clang type for
CVaListPointer.
- Drops the implicit conversion from CVaListPointer to COpaquePointer.
All together, this provides more type-safety for functions using va_list on
x86_64.
Swift SVN r17307
We'd rather show dispatch_async as
// new
func dispatch_async(queue: dispatch_queue_t!, block: dispatch_block_t!)
than
// old
func dispatch_async(queue: dispatch_queue_t!, block: (() -> Void)!)
which was only happening because we were trying to hide the @objc_block
annotation when possible. That's not necessary when we have a typealias.
<rdar://problem/16679280>
Swift SVN r17273
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
import them as the underlying class type, then wrap that in
Unmanaged<T>.
Also, trust (and fix) hinting to tell us when to wrap something
in an optional type.
Swift SVN r17207
Also, if the generated header says that a class or protocol is available in
a module, but we can't find it, we should treat the decl as missing rather
than pretending it's a normal Objective-C decl.
Part of <rdar://problem/16776466>
Swift SVN r17175
As part of this, use tail allocation to reduce the memory footprint of
TupleExprs. Use factory methods to make it easier to construct.
I'll be using this information in a follow-on patch. SourceKit
probably wants it as well.
Swift SVN r17129
Previously, this declaration:
typedef NS_OPTIONS(NSUInteger, NSABitmapFormat5) {
NSAA16d,
NSAB32d,
};
...would import with members .A16d and .B32d, which is not necessarily
correct. (Is it "NS_AA_16d", or "NSA_A_16d"?) Be more conservative here.
Swift SVN r17125
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
