We needed some patching up to convert negative enum constants into proper negative IntegerLiteralExprs in the imported Swift AST, to handle the obnoxious INT_MIN edge case, and to handle "negative" values of unsigned enums.
Swift SVN r10005
Clean up ListMaker and get it compiling again. Delete all of the
stubbed-out table view delegate methods now that they're optional,
fixing the crash when dragging items <rdar://problem/14582991>.
Swift SVN r9995
Swift enum cases are already namespaced to their type, but Cocoa NS_ENUM constants are manually namespaced with a common prefix, so if we imported them as-is, we'd end up with expressions like 'NSStringSearchOptions.NSStringSearchCaseSensitive'. To make this a bit nicer, look for a common prefix of camel-case words among all of the constants in the enum, and remove that prefix from the enum case names in the Swift interface.
In the case of a single enum case, we have no basis for determining a prefix, so do nothing. This case doesn't come up in the frameworks (that I can see).
Swift SVN r9993
Previously, the Parser and BranchStmt typedef-ed ExprStmtOrDecl as a pointer union. Using typedef made the objects compatible, but did not allow us to extend the type with helper methods, such as getSourceRange(), which is something you can get on all of the AST objects. This patch introduces ASTNode that subclasses from PointerUnion and is used by both parser and BranchStmt.
Swift SVN r9971
When we see an enum declaration in the Clang importer, look at its source location to see if it was produced as part of an NS_ENUM macro expansion. If so, take the 'Enum' route through the Clang importer and import it as a Swift enum. This will break things until we have end-to-end support for Clang-imported enums, so hide it behind an -import-ns-enum switch for now.
Swift SVN r9951
Whatever kind of Swift decl we cons up for a Clang enum, add it to the externals list so we can pick it up and emit Swift metadata for it in IRGen. Fixes <rdar://problem/15242452>.
Swift SVN r9801
NSDictionary's implementation of -objectForKeyedSubscript: takes an id
instead of 'id <NSCopying>' because a dictionary could in theory have non-
copyable keys. However, Swift requires the getter and setter for a subscript
operator to have the same type. Therefore, we unilaterally import the
getter as 'subscript(key : NSCopyingProto) { get }', and just rely on the
fact that the representation of 'id' and 'id <NSCopying>' is the same.
What doesn't change:
- objectForKey() still takes a plain 'id', in the rare cases that that is
useful.
- Looping over an NSDictionary still gives you (id, id) pairs, on the grounds
that if you actually want to do something with the key, it probably isn't
going to be copying it. Without this, doing something useful with the key
would require an explicit cast.
- If any other subscript indexes don't match up, the subscript is dropped
(r8636).
<rdar://problem/14397360>
Swift SVN r9424
of having a ton of ad-hoc bools in it. This allows us to consolidate a ton of
boilerplate, eliminating 250 lines of code:
17 files changed, 435 insertions(+), 662 deletions(-)
2) This eliminates the special case for weak and unowned attributes, which previously
didn't show up in Attr.def.
3) While we're at it, keep track of proper source locations for each attribute, and
use these to emit diagnostics pointing at the attribute in question instead of at
a funcdecl or the @ sign.
4) Fix axle attributes, which had vertex and fragment swapped.
Swift SVN r9263
Now that we have a solid Optional-based story for dynamic casts, it's no longer needed, and can be expressed as '(x as T)!'. Future refinement of the 'as' syntax will deal with the unfortunate extra parens.
Swift SVN r9181
Pull the implicit 'Self' associated type out of the protocol and into
an implicitly-declared generic parameter list for the protocol. This
makes all of the methods of a protocol polymorphic, e.g., given
protocol P {
typealias Assoc
func getAssoc() -> Assoc
}
the type of P.getAssoc is:
<Self : P> (self : @inout P) -> () -> Self.Assoc
This directly expresses the notion that protocol methods are
polymorphic, even though 'Self' is always implicitly bound. It can be
used to simplify IRgen and some parts of the type checker, as well as
laying more of the groundwork for default definitions within
protocols as well as sundry other improvements to the generics
system.
There are a number of moving parts that needed to be updated in tandem
for this. In no particular order:
- Protocols always get an implicit generic parameter list, with a
single generic parameter 'Self' that conforms to the protocol itself.
- The 'Self' archetype type now knows which protocol it is
associated with (since we can no longer point it at the Self
associated type declaration).
- Protocol methods now get interface types (i.e., canonicalizable
dependent function types).
- The "all archetypes" list for a polymorphic function type does not
include the Self archetype nor its nested types, because they are
handled implicitly. This avoids the need to rework IRGen's handling
of archetypes for now.
- When (de-)serializing a XREF for a function type that has an
interface type, use the canonicalized interface type, which can be
meaningfully compared during deserialization (unlike the
PolymorphicFunctionType we'd otherwise be dealing with).
- Added a SIL-specific type attribute @sil_self, which extracts the
'Self' archetype of a protocol, because we can no longer refer to
the associated type "P.Self".
Swift SVN r9066
Argument patterns create pseudo-named patterns, so make them implicit and ignore them when scanning for explicit source information.
Also make sure that the clang importer sets the HasSelectorStyleSignature bit appropriately.
Swift SVN r8803
The name used for name lookup of subscript operators is "__subscript",
but when looking into an Objective-C module we instead need to look
for methods with the subscripting selectors, e.g.,
objectAtIndexedSubscript:/objectForKeyedSubscript:. Do so, and make
sure that deserializing the method first still creates the subscript
declaration.
Fixes the majority of <rdar://problem/14656624>. We can subscript 'id' now.
Swift SVN r8700
These are the terms sent out in the proposal last week and described in
StoredAndComputedVariables.rst.
variable
anything declared with 'var'
member variable
a variable inside a nominal type (may be an instance variable or not)
property
another term for "member variable"
computed variable
a variable with a custom getter or setter
stored variable
a variable with backing storage; any non-computed variable
These terms pre-exist in SIL and IRGen, so I only attempted to solidify
their definitions. Other than the use of "field" for "tuple element",
none of these should be exposed to users.
field
a tuple element, or
the underlying storage for a stored variable in a struct or class
physical
describes an entity whose value can be accessed directly
logical
describes an entity whose value must be accessed through some accessor
Swift SVN r8698
Instead of synthesizing Swift code for the property and subscript
getters and setters we import from Objective-C, just create the
declarations and mark them as being Objective-C (foreign) entry
points. This means that we'll use the Objective-C entry points (via
objc_msgSend).
Swift SVN r8692
Instead, pass a LazyResolver down through name lookup, and type-check
things on demand. Most of the churn here is simply passing that extra
LazyResolver parameter through.
This doesn't actually work yet; the later commits will fix this.
Swift SVN r8643
The hack was that __attribute__((iboutletcollection(NSView))) can be
specified on a collection property to provide its value type, and the
ClangImporter library co-opted that as a way to import NSArray properties
as NSTypedArray<NSView> (or whatever), a layout-compatible Swift struct
type that provided a typed (runtime-checked) view of an NSArray. The
implementation of NSTypedArray was never completed, however; none of
our sample code is actually using it; and it turns out to be problematic
for some instances of lazy type checking (because NSTypedArray is defined
in Swift). Remove it; we'll revisit this later.
Swift SVN r8639
If the getter and setter have different index types, there's not much we can
do in Swift. It's better to not pretend to handle this (which currently leads
to a crash in SIL verification). Fortunately, this is likely very rare in
Objective-C, except for one special case:
We do plan to special-case this for NSDictionary, which has keys of type
'id' while NSMutableDictionary's setter uses 'id <NSCopying>'.
Swift SVN r8638
Introduce a bit in Expr to indicate whether the expression is implicit and decouple the implicitness
of an expression from whether it has a source location or not.
This allows implicit expressions to be able to point at the source location where they originated from.
It also allows decoupling the implicitness of a parent from its children, so for example, an implicit CallExpr
can have an explicit parameter value.
Swift SVN r8600
Iff an enum declares a raw type, its cases may declare raw values or else have them assigned to them implicitly by autoincrementing from zero, like in C. If the raw type is float-, string-, or char-literal-convertible, there is no autoincrement, and the raw values must all be explicit. The raw type is rejected if any cases have payloads.
We don't yet diagnose duplicate raw values. That'll come next. We also don't yet serialize or deserialize the raw values. We don't strictly need to do this, since the RawRepresentable protocol conformance will be exported from the module as API, but Jordan pointed out that, for fragile raw values, this would be good for documents/jump-to-definition purposes, so we have a plan for only serializing the literals without having to deal with fully general expression serialization.
Swift SVN r8545
Introduce an EnumCaseDecl for source fidelity to track the 'case' location and ordering of EnumElementDecls. Parse a comma-separated list of EnumElementDecls after a 'case' token.
Swift SVN r8509
Improve the type checker to create implicit DestructorDecls, tighten the
assertion in ImplicitReturnLocation::getImplicitReturnLoc(), and add a verifier
check that a class in a type checked AST always has exactly one destructor.
SILGen used to generate a destructor if the class does not have a
DestructorDecl. SILGen used to put the ClassDecl inside the SILLocation for
the destructor SIL code. This is not a very clean solution: in this case
ImplicitReturnLocation SILLocations contain ClassDecl, which is surprising.
rdar://14970972 Implicit destructors should have AST nodes
Swift SVN r8498
This makes it impossible to call an "init" method from Swift code; one
must construct an object, delegate to another constructor (not yet
implemented), or chain to a superclass constructor.
Swift SVN r8421
When we import an Objective-C init method into Swift as a constructor,
the Clang importer currently synthesizes both a +alloc call (used by
the allocating constructor) and a body that forwards to the
corresponding init method. Eliminate the body and stop emitting an
initializing constructor at all: instead, the allocating constructor
will invoke the init method through objc_msgSend.
Swift SVN r8420
Implement the new rules for mapping between selector names and
constructors. The selector for a given constructor is formed by
looking at the names of the constructor parameters:
* For the first parameter, prepend "init" to the parameter name and
uppercase the first letter of the parameter name. Append ':' if
there are > 1 parameters or the parameter has non-empty-tuple type.
* For the remaining parameters, the name of each parameter followed
by ':'.
When a parameter doesn't exist, assume that the parameter name is the
empty string.
And, because I failed to commit it separately, support selector-style
declarations of constructor parameters so that we can actually write
constructors nicely, e.g.:
// selector is initWithFoo:bar:
constructor withFoo(foo : Foo) bar(bar : Bar) { ... }
Swift SVN r8361
AnyFunctionRef is a universal function reference that can wrap all AST nodes
that represent functions and exposes a common interface to them. Use it in two
places in SIL where CapturingExpr was used previously.
AnyFunctionRef allows further simplifications in other places, but these will
be done separately.
Swift SVN r8239
