Outside of a container, semicolons after decls are just parsed as SemiStmts.
Inside a container, though, we only allow decls...but we should still allow
trailing (delimiting?) semicolons.
If you have multiple semicolons in a row, though, that's probably a typo,
so parseDecl will now also complain (error) if it sees a semicolon where
a decl is expected.
<rdar://problem/12540877>
Swift SVN r3051
static method to call it, to make it more explicit what is happening. Avoid
using TypeLoc::withoutLoc for function definitions; instead, just use an empty
TypeLoc.
Swift SVN r2606
This is much more convenient for IRGen, and gives us a reasonable representation for a static
polymorphic function on a polymorphic type.
I had to hack up irgen::emitArrayInjectionCall a bit to make the rest of this patch work; John, please
revert those bits once emitCallee is fixed.
Swift SVN r2488
have a record of how the member is being specialized for the given
context. To do this, I also had to patch up the DeclContext for
template parameters.
Swift SVN r2483
analysis for patterns.
Major changes:
1. We no longer try to compute the types of functions in the parser.
2. The type of a function always matches the type of the argument patterns.
3. Every FuncDecl now has a corresponding FuncExpr; that FuncExpr might not
have a body, though.
4. We now use a new class "ExprHandle" so that both a pattern and a type
can hold a reference to the same expression.
Hopefully this will be a more reasonable foundation for further changes to
how we compute the types of FuncDecls in generics and for the implementation
of type location information.
Swift SVN r2370
method to initialize the members. This doesn't matter so much
for structs (the generated IR is essentially equivalent except for
small structs), but on classes, we don't want to make "new X" generate
code that knows about metadata/destructors/etc for the class X.
Also, make sure classes always have a constructor. (We haven't really
discussed the rules for implicitly declared constructors, so for now,
the rule is just "generate an implicit constructor if there is no
explicit constructor". We'll want to revisit this when we actually
design object construction.)
Swift SVN r2361
the various NominalDecl subclasses into a single NominalType* member
in NominalDecl. Use it to make TypeDecl::getDeclaredType() more
efficient/simpler, and simplify the ProtocolDecl/ProtocolType
interaction along the way.
No functionality change.
Swift SVN r2298
There are currently two places where you can use a static function defined on a protocol:
on an object with the type of the protocol (discarding the base), and on an archetype in a generic function. The AST for the protocol object case is probably okay;
the AST for the generic case is almost certainly wrong, but that whole area isn't really stable at the moment anyway. The proposal in rdar://problem/11448251 will
add a third way: operators on protocols will be found by overload resolution. (Having static functions on protocols opens up the possibility of metaprotocols,
but I don't think I need to worry about that for the moment.)
Swift SVN r2211
introduce the generic type parameters (which are simply type aliases
for a to-be-determined archetype type) into scope for name
lookup. We can now parse something like
func f<T, U : Range>(x : T, y : U) { }
but there is no semantic analysis or even basic safety checking (yet).
Swift SVN r2197
protocols the underlying type of the type alias shall conform to. This
isn't super-motivating by itself (one could extend the underying type
instead), but serves as documentation, makes typealiases provide the
same syntax as other nominal types in this regard, and will also be
used to specify requirements on associated types.
Swift SVN r2133
using the term "unresolved" in expressions for a while, and it fits
for types better than "dependent type."
The term "dependent type" will likely come back at some point to mean
"involves an archetype".
Swift SVN r1962
A user-defined conversion function is an instance method that accepts
an empty tuple and returns a value of the type we're converting to,
has the [conversion] attribute, and is named __conversion. The last of
these restrictions is a temporary hack to work around our inability to
perform a lookup across all extensions for "every function with the
conversion attribute", and shouldn't last too long.
As in C++, we only get one user-defined conversion function. Unlike in
C++, a constructor is not (and cannot) be a conversion function.
Introduce NSString <-> String conversion functions, but leave the
runtime implementations as stubs for Dave to fill in.
Swift SVN r1921
