As with the monadic '?', we treat any left-bound '!' as a postfix
operator. Currently, it extracts the value of its optional
subexpression, failing at run-time if the optional is empty.
Swift SVN r8948
When building the (dependent) interface type of generic functions,
don't resolve any generic parameter types to archetypes, even those at
outer levels. Instead, keep everything dependent.
As a special case, the type of 'self' gets baked into the parameter
patterns with archetypes, so reconstruct the 'self' type ourselves.
The actual output of this is still frustratingly untestable, but we
get decent coverage because all of the type checking of generic
functions goes through here first.
Swift SVN r8936
If an enum has a valid raw type, synthesize a RawType associated type along with fromRaw and toRaw methods.
An implicit conformance to RawRepresentable is not yet set up. This synthesis may need to be done earlier in order for the names to be available during type-checking of definitions in the enum too.
Swift SVN r8890
Parse '_' as a DiscardAssignmentExpr. Type-check it as an lvalue, and check that it only appears in the LHS of AssignExprs. During matching pattern resolution, convert it into an AnyPattern. In SILGen, when we see '_' in the LHS of an assignment, ignore the corresponding RHS rvalue.
Swift SVN r8848
Though we plan to revamp the casting syntax, our general plan is for this form of cast, which does a conditional cast and returns an Optional<T> result, to be the one that survives. Parse the status-quo syntax 'x as? T' and type-check it. While we're here, refresh some fixits for redundant casts that referred to the now defunct 'as T' coercion syntax to completely remove whatever cast was in the source code.
Swift SVN r8805
Require that either T be default constructible or that the user provide a closure that maps indices to initial values. We don't actually call the closure yet to initialize the array; that's blocked on function abstraction difference <rdar://problem/13251236>.
Swift SVN r8801
Instead of relying on the subpattern being a well-formed TuplePattern, let's track our own subelements so we can associate them to properties and validate them ourselves.
Swift SVN r8771
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
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
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
If an OpaqueValueExpr is only used in one place, mark it as such. SIL
generation will then elide the retain/release pair associated with
each reference to the opaque value, instead consuming the value at the
point of use.
Swift SVN r8072
These helper expressions will eventually be used by SILGen to help
package up the optional values. I expect that we'll eventually have
library builtins for this, so consider this a stop-gap until those
appear.
As part of this, make OpaqueValueExpr a bit more usable: it can now
persist in the AST as a placeholder, but its uses must be within AST
subtrees of some specific introduction point (similarly to how Clang's
OpaqueValueExpr works).
Swift SVN r8051
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
MemberRefExpr now uses ConcreteDeclRef to refer to its member, which
includes the substitutions and obviates the need for
GenericMemberRefExpr.
Swift SVN r7842
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
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
