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
Previously, we followed an early exit for bodiless constructors/destructors/subscripts.
This prevented some diagnostics and full AST class setup in SIL parsing mode and for bodiless subscripts in general.
Thanks for the suggestion Dmitry!
Swift SVN r8672
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
Allow the inheritance clauses of enums to reference a non-protocol type as their raw type. For now, only diagnose that the raw type occurs first, that there's only one raw type, that there are no circularities in raw types, like we do for class inheritance, and additionally that the raw type is literal convertible, which we'll require for the raw values of the cases.
Swift SVN r8529
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
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
Given an object of type DynamicLookup.metatype, allow us to find both
static and instance methods.
Sema only; SILGen and IRGen changes to come.
Swift SVN r8290
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
No testcase because this is not testable now -- this function is only used in
diagnostics of value redefinitions, which are broken now for redefinitions of
member functions.
Swift SVN r8187
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
global variables used by functions in the capture list as well.
SILGen and other things that don't care about these (i.e., all
current current clients) filter the list to get what they want.
This is needed for future definite init improvements, and unblocked
by Doug's patch in r8039 (thanks! :)
No functionality change.
Swift SVN r8045
Clean up the "can be accessed by dynamic lookup" predicate so that it
checks for a generic context. We no longer need to do the checking in
name lookup, since this means that the dynamic lookup table won't have
anything we can't use (thanks Jordan!). Drop the [objc] allowance for
members of a generic context: it still leaves us with a very weird
case of messaging something when we can't even figure out the type
that we think the object has.
Extend the walk searching for members to include inner classes within
structs, so we get all of the members globally.
Swift SVN r7799
We only know the type of functions and vars at the time we create them,
and sometimes not even those. Just use setType() in those constructors
and make all other ValueDecls simpler.
Swift SVN r7756
Unlike normal overload resolution, where we always want the
most-specialized, overriding result, overload resolution for dynamic
lookups favors results in superclasses to those in subclasses, because
we want to put the least requirements on the object
type. Additionally, we don't allow overload resolution to select among
results that come from different classes or protocols.
Swift SVN r7743
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
This breaks the type-canonicalization link between a generic parameter
type and the archetype to which it maps. Generic type parameter types
are now separate entities (that can eventually be canonicalized) from
archetypes (rather than just being sugar).
Most of the front end still traffics in archetypes. As a step away
from this, allow us to type-check the generic parameter list's types
prior to wiring the generic type parameter declarations to archetypes,
using the new "dependent" member type to describe assocaited
types. The archetype builder understands dependent member types and
uses them to map down to associated types when building archetypes.
Once we have assigned archetypes, we revert the dependent identifier
types within the generic parameter list to an un-type-checked state
and do the type checking again in the presence of archetypes, so that
nothing beyond the generic-parameter-list checking code has to deal
with dependent types. We'll creep support out to other dependent types
elsewhere over time.
Swift SVN r7462
