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
Fixes two bugs in Clang importer and deserialization code that were found by
the verifier:
(1) FuncExprs were created with a null FuncDecl
(2) BoundGenericType that was created by Clang importer for UnsafePtr<> and
other magic types did not have substitutions.
Swift SVN r8073
ConstructorDecl::getBody() and DestructorDecl::getBody() return 'BraceStmt *'.
After changing the AST representation for functions, FuncDecl::getBody() will
return 'BraceStmt *' and FuncDecl::getFuncExpr() will be gone.
Swift SVN r8050
That is, 1234 is a CInt, 1234U is a CUnsignedInt, and 1234LL is a CLongLong.
Oh, and 3.14F is a CFloat.
One caveat here is that it is not actually possible in C to write a literal
INT_MIN:
-0x80000000 is two tokens and the literal part is unsigned
(-INT_MAX - 1) is several tokens
I've simply dropped this test for now, but it might be confusing in the rare
case where an INT_MIN-like value is used as a sentinel.
<rdar://problem/13839025>
Swift SVN r7639
This was not likely an error-free change. Where you see problems
please correct them. This went through a fairly tedious audit
before committing, but comments might have been changed incorrectly,
not changed at all, etc.
Swift SVN r7631
Each nested archetype X.Y corresponds to an associated type named 'Y'
within one of the protocols to which X conforms. Record the associated
type within the archetype itself. When performing type substitutions,
use that associated type to extract the corresponding type witness
rather than looking for the type itself. This is technically more
correct (since we used the type witness for type checking), and a step
toward pulling type substitutions into the AST.
Swift SVN r7624
Previously, we were creating the type corresponding to
class/struct/union declarations as part of creating the declaration
node, which happens at parse time. The main problem with this (at the
moment) occurs with nested nominal types, where we'd end up with the
wrong "parent" type when the type was nested inside an extension
(because the extension hadn't been resolved at the time we accessed
the parent's type). Amusingly, only code completion observed this,
because the canonical type system hid the problem. The churn in the
code-completion tests come from the fact that we now have the proper
declared type for class/struct/union declarations within extensions.
Take a step toward order-independent type checking by setting the type
of a class/struct/union declaration in type checking when we either
find the declaration (e.g., due to name lookup) or walk to the
declaration (in our walk of the whole translation unit to type-check
it), extending the existing TypeChecker::validateTypeDecl() entry
point and adding a few more callers.
The removeShadowedDecls() hack is awful; this needs to move out to the
callers, which should be abstracted better in the type checker anyway.
Incremental, non-obvious step toward fixing the representation of
polymorphic function types. This yak has a *lot* of hair.
Swift SVN r7444
At present, this is a distinction without a difference. However, it's
a step toward detangling archetypes from the interface of a
polymorphic function.
Swift SVN r7405
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
