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
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
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
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
and only later adjust the type for the manner in which
it is actually being used.
This gives us a foundation on which to build a consistent
and defensible model for importing typedefs.
Also fix a subtle problem with typedefs imported from
multiple clang modules.
Swift SVN r17079
Introduce a model where an argument name is a keyword argument if:
- It is an argument to an initializer, or
- It is an argument to a method after the first argument, or
- It is preceded by a back-tick (`), or
- Both a keyword argument name and an internal parameter name are
specified.
Provide diagnostics Fix-Its to clean up cases where the user is
probably confused, i.e.,
- "_ x: Int" -> "x: Int" where "x" would not have been a keyword
argument anyway
- "x x: Int" -> "`x: Int"
This covers the compiler side of <rdar://problem/16741975> and
<rdar://problem/16742001>.
Update the AST printer to print in this form, never printing just
a type for a parameter name because we're also going to adopt
<rdar://problem/16737312> and it was easier to move the tests once
rather than twice.
Standard library and test updates coming separately.
Swift SVN r17056
(and a similar issue for subscripts)
In Cocoa, a property can be declared readonly in the public interface of a
class and readwrite in a class extension. Similarly, a protocol can require
a readable property, but a category then declares the property as readwrite.
Swift doesn't like having two of the same declaration, and which one ended
up being used was order-dependent.
This change doesn't really fix the problem, but it does paper over it.
Now, when the importer sees a redeclaration of a readonly property as
readwrite, it forcibly updates the existing property with the new setter.
This isn't entirely correct; the redeclaration doesn't show up in its category,
and this doesn't respect visibility (i.e. the change to readwrite occurs in
a separate module that isn't visible in all source files). (But extensions
don't respect visibility in any other way, either, even in pure Swift code.)
At its heart, this is just a mismatch between Objective-C allowing
redeclarations that add capabilities and Swift not having redeclarations
at all. At some point, it may make more sense to model this as an overload,
or to mark the original declaration invalid, but for now this seems to be
the most contained change we can get that fixes the problem.
<rdar://problem/16692921>
Swift SVN r16832
Hack the clang importer to drop the 'otherButtonTitles:' argument when we see the UIActionSheet or UIAlertView init methods, so we'll end up importing them as the non-variadic initializers added by the overlay.
Swift SVN r16717
Previously, we didn't correctly handle acronyms as single words, leading to
importing the NS16BitLittleEndianBitmapFormat enumerator of NSBitmapFormat as
"S16BitLittleEndianBitmapFormat". Now we get "NS16BitLittleEndianBitmapFormat",
which is a little better. See the examples for a few more ways this shakes out.
<rdar://problem/16683848>
Swift SVN r16682
them with uses of TypeExpr instead. The remaining uses of
MetaTypeExpr (which will be renamed soon) are places where we
are applying the ".dynamicType" virtual property to an expression.
Unadorned uses of types in code, e.g. the Int in "Int.self" are
now represented with TypeExpr.
One unfortunate travesty that doing this work revealed is that we
are extremely sloppy and terrible about maintaining location information
in implicitly generated decls, and our invariants vary quite a bit. This
is really horrible, but I'm not sure whether I'll go fix the hacks or not.
This patch perpetuates the existing crimes, but makes them more visible.
NFC!
Swift SVN r16646
Before we create a new initializer, check whether it would collide
with existing initializers. If it's better than the existing
initializer, mark the existing one as unavailable; if it's not better,
don't build it.
In support of this, we tweak a few things w.r.t. unavailble
declarations:
- An unavailable declaration is shadowed by an available one,
- Don't emit SIL unavailable, imported initializers
This fixes the last problem with <rdar://problem/16509024>.
Swift SVN r16611
The use of ASTContext-allocated arrays to store the members of nominal
type declarations and the extensions thereof is an
abomination. Instead, introduce the notion of an "iterable"
declaration context, which keeps track of the declarations within that
context (stored as a singly-linked list) and allows iteration over
them. When a member is added, it will also make sure that the member
goes into the lookup table for its context immediately.
This eliminates a ton of wasted memory when we have to reallocate the
members arrays for types and extensions, and moves us toward a much
more sane model. The only functionality change here is that the Clang
importer no longer puts subscript declarations into the wrong class,
nor does it nested a C struct within another C struct.
Swift SVN r16572
NFC. DeclRange is a range over DeclIterators, and is used rather than
ArrayRef<Decl*> to retrieve the members of a nominal type declaration
or extension thereof. The intent is to change the representation of
DeclRange next.
Swift SVN r16571
Basically, if an imported enumeration case is referenced without qualification as an argument to a '==' application (E.g., "foo.bar == .Baz"), and the enumeration type had not previously been resolved, overloads to '==' will be added to the global scope while performing overload resolution. This means the overloads will be ignored while solving for that application, but will be available for subsequent applications. (So you'll get an "expression does not type check" error the first time around, but not for subsequent applications of '==' to that enumeration type.)
The Equatable protocol is rather lightweight, however, and adding it to imported types directly results in no meaningful overhead to type check performance; we should just add it outright. As things evolve, though, it'll be worth considering how to make the type checker more amenable to lazy declarations.
Swift SVN r16557
As noted in the FIXME, this is a hack. We need to do a bit of
infrastructure work before we can detect and suppress duplicates like
this in a meaningful way. Name lookup already does a similar thing for
ambiguity-resolution purposes. However, doing this here makes the
printed modules much cleaner.
look significantly more reasonable.
Swift SVN r16531
Factory initializers express an initializer that produces an object of
the given type, but is not inherited and not designated. Although they
have a syntactic form for presentation purposes (-> ClassName), there
is no way to specify or implement them within Swift. Rather, factory
initializers are created when importing an Objective-C factory method
that returns the class type rather than instancetype.
Swift SVN r16528
Convenience factory initializers are convenience initializers produced
by importing an Objective-C factory method as a convenience
initializer. The distinction is currently only used to eliminate the
awful layering violation I recently introduced in name lookup, which
was consulting Clang AST nodes directly. It will also be useful in
SILGen.
Swift SVN r16527
Introduce CtorInitializerKind to describe the kind of an enum, rather
than a bool, to make way for more initializer kinds in the future.
Swift SVN r16525
Help guide users over to the initializers with the 'unavailable' message, e.g.,
objc_factory_method.swift:24:18: error: 'hiveWithQueen' is unavailable: use
initializer 'Hive(withQueen:)'
Swift SVN r16498
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
Switch the "does this imported declaration override a declaration in
the superclass?" check to perform lookups based on what actually gets
into Swift, rather than looking into the Objective-C class, because
the Objective-C class isn't representative.
Additionally, explicitly avoid adding implicit initializers to an
Objective-C-imported class.
Problems fixed here are tested by an upcoming commit.
Swift SVN r16464
