Teach TuplePatternElt to keep track of the kind of the default
argument: none, normal (provided by calling into the appropriate
callee generator), __FILE__, __LINE__, or __COLUMN__. For the latter
three cases, the type checker forms the appropriate argument as part
of the call.
The actual default argument expression will only be held in the tuple
pattern element when we've parsed it; it won't be serialized or
deserialized, because only the defining module cares. This is a step
toward eliminate the initialization expression from tuple types.
The extension to TupleShuffleExpr is a hack, which will also be
replicated in ScalarToTupleExpr, until we finally rework the
representation of TupleShuffleExpr (<rdar://problem/12340004>).
Swift SVN r6299
This change switches SIL generation for default values over to using
the default argument generators we started emitting in r6258. Note
that we don't use these entry points for default arguments involving
__FILE__, __LINE__, or __COLUMN___. These will need a different kind
of magic.
Swift SVN r6295
Refactored the function calling conventions,"thin" attribute, and other extra function info bits to be stored inside the TypeBits. The isAutoClosure and IsBlock bits are also pulled up into AnyFunctionType.
This should make it easier to construct and propagate the attributes. Using ExtInfo struct to simplify the FunctionType is coming up next.
Swift SVN r6284
As per Chris's suggestion (review of r6152), further refactored SILLocation not to derive from PointerUnion3 but to include it as a member.
In addition, added some template magic to make sure we don't have to chain dyn_casts, which I suspect will be/is happening a lot with SILLocation:
Ex:
- if (auto E = Func.dyn_cast<Expr*>()) {
- if (const FuncExpr *FE = dyn_cast<FuncExpr>(E))
- return SILLocation(FE->getBody())
+ if (const FuncExpr *FE = Func.getAs<FuncExpr>())
+ return SILLocation(FE->getBody());
Swift SVN r6283
Eventually TypeLocs coming from the Parser will contain only a TypeRepr and the TypeChecker will resolve and add the type.
Passing a TypeLoc to a diagnostic means "print as user written" (even before typechecking)
and if there is no TypeRepr (e.g. due to a TypeLoc coming from a module without location info) print the type.
Swift SVN r6280
If we see '.Foo' or '.Foo(...)' in a case, resolve it as a OneOfElementPattern with element to be determined at type-checking time. If we see 'A.B' or 'A.B(...)', try to resolve 'A.B' as a qualified reference to a OneOfElementDecl, and resolve the expression as a OneOfElementPattern referencing that decl if we find one. During type-checking, resolve the element decl for unresolved OneOfElementPatterns, then match the subpattern to the type of the element's associated data (or void if it has none).
A few cases don't yet work right that ought to:
- Qualified references to generic oneof cases with generic arguments elided, e.g. 'case Optional.None:'
- Qualified references to generic oneof cases through a module, e.g. 'case swift.Optional<Int>.None:'
Swift SVN r6278
When we form a tuple that uses default arguments, find the source of
the default arguments (which will be a function or constructor
declaration). This information will eventually be introduced into the
AST.
Swift SVN r6277
The semantics of varargs (only for the last element) make it more appropriate as a property of the TuplePattern.
Also free the Parser from needing to construct synthetic types (ArraySlice for type of vararg element) to
accommodate the TypeChecker and move the logic to the TypeChecker. This will be more beneficial when the parser stops
creating types in general.
Swift SVN r6271
In the resilience model for default arguments, the presence of a
default argument is API, but its specific value is not. Thus, the
actual default argument values can evolve over time. To implement
this, for each default argument, we emit a function that
takes no arguments and produces the default value for that
argument. The caller will then call that function to form the default
argument.
This commit emits these functions for each default argument, even
though they are not currently being called. This is part of
<rdar://problem/11561185>.
We'll probably want a different calling convention for these functions
that preserves all registers, since they will often end up being very
trivial functions.
Swift SVN r6260
functions to use raw_ostream like the rest of clang and swift. Also add a
comment that these functions are intended for debugging only.
Swift SVN r6212
Give oneof bodies syntax consistent with other NominalTypes. Give oneof elements first-class declaration syntax using the 'case' introducer, as suggested by Jordan. Oneofs can contain 'case' decls, functions, properties, and constructors, but not physical ivars. Non-oneof scopes cannot contain 'case' decls. Add some QoI to the oneof 'case' parser to also parse and complain about things that resemble switch 'case' labels inside decl contexts.
Swift SVN r6211
sil_type: '$' '*'? attribute-list (generic-params)? type
Refactor parseTypeAnnotation to separate applyAttributeToType which can be
used from SILParser.
Swift SVN r6209
Introduces very basic support for diagnosing ambiguous expressions,
where the source of the ambiguity is a reference to an overloaded
name. Simple example:
t.swift:4:1: error: ambiguous use of 'f0'
f0(1, 2)
^
t.swift:1:6: note: found this candidate
func f0(i : Int, d : Double) {}
^
t.swift:2:6: note: found this candidate
func f0(d : Double, i : Int) {}
^
There's a lot of work needed to make this cleaner, but perhaps it will
ease the pain of developing the library <rdar://problem/14277889>.
Swift SVN r6195
These still need to be serialized, because they are one-to-one with the
type's protocol list, but don't actually require any data. Found on
attempting to emit a module for the standard library.
Most of the churn here is moving Interleave.h to a more general STLExtras.h.
Swift SVN r6167
Per r6154, this is now dead code. The only places we allow default
arguments will be visited by normal type validation, so there's
nothing specific to do here.
Swift SVN r6157
