Attribute [transparent] on extensions should apply to all members(functions, properties) of that extension.
Addresses radar://15035271.
Swift SVN r8735
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
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
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
for all AbstractFunctionDecl's. Refactor ASTDump of AbstractFunctionDecl's
to all go through the same funnel point and print it in the right place.
Swift SVN r8242
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
and remove DeclContext base class from FuncDecl, ConstructorDecl and
DestructorDecl
This decreases the number of DeclContexts to 7 and allows us to apply
alignas(8) to DeclContext.
Swift SVN r8186
This should allow declarations inside protocols to mangle successfully, which is needed by SourceKit to be able to use mangled names as unique decl identifiers. I'm also planning to use mangled protocol decls to name generic curry thunk symbols.
This only introduces a mangling for independent associated types. I think we will eventually want to mangle dependent associated types (such as T.AssocType for an archetype T : SomeProtocol) with a non-indexed mangling too, but this doesn't do that yet.
Swift SVN r8148
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
The new ConcreteDeclRef class provides a possibly-speciaized reference
to a declaration, which allows DynamicMemberRefExpr to refer to both
generic and non-generic members. without having to split the AST node.
Swift SVN r7839
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
When performing member lookup into an existential that involves the
DynamicLookup protocol, look into all classes and protocols for that
member. References to anything found via this lookup mechanism are
returned as instances of Optional.
This introduces the basic lookup mechanics into the type
checker. There are still numerous issues to work through:
- Subscripting isn't supported yet
- There's no SILGen or IRGen support
- The ASTs probably aren't good enough for the above anyway
- References to generics will be broken
- Ambiguity resolution or non-resolution
Thanks to Jordan for the patch wiring up DynamicLookup.
Swift SVN r7689
