2. This exposed a bug: when parsing structs, we weren't adding all decls to the translation unit, we were just adding the type alias.
3. This exposed that TypeChecking wasn't handling OneOfElementDecl.
4. Introduce a new NLKind enum in NameLookup instead of passing around a bool.
5. Have unqualified lookup that returns an overload set form a new OverloadSetRefExpr, which has dependent type.
6. Enhance various stuff to handle OverloadSetRefExpr. It's still not fully handled yet though, so it can't be used for anything useful.
7. Change Expr.cpp to print types with << instead of T->print(OS) which is simpler and correct in the face of null.
Swift SVN r351
This didn't manifest as a bug yet, but it doesn't make sense to wait until it does. This aspect of grouping parens is a syntactic issue, so make the creator of TupleExpr specify whether the expr is a grouping paren or not and persist this.
Swift SVN r312
#1: Change type conversion errors to print the types involved, making the diagnostic better. We still don't have ranges, but it is progress.
#2: Reimplement support for anonymous closure arguments (e.g. func($0+$1)) where func takes a closure, step #1.
- This removes AnonDecl, replacing it with AnonClosureArgExpr. $0 and friends have to be expressions since they don't get a type and don't get resolved until TypeChecking.
- For now we just replace the existing broken support, a future step is to implement type checking support for them.
Swift SVN r278
Highlights of this include:
1) most of SemaExpr is gone now, when parsing, all expressions are assigned null types.
2) the introduction of a new TypeChecking pass, which assigns types to expressions, and checks their constraints.
3) ElementRefDecl now properly stores an access path for what it is accessing, and ElementRefDecl's get added to the AST.
4) The parser is much much simpler for expressions now, it just collects lists of primary exprs into SequenceExprs unconditionally.
5) This means that formation of binary expressions, function application etc is now done by TypeChecking. This is actually simpler, though admittedly surprising.
6) This introduces a new -parse-dump mode which just parses but does not perform name binding or type checking.
I've been working on this for a while and it is still quite broken: it still doesn't handle anondecls at all, doesn't perform conversion checking for default tuple elements, has missing pieces of varname name binding etc. However, there is no reason to not crash land it now, it's not like I'm going to break anyone else.
Swift SVN r262
data.swift:114:10: error: ambiguous expression could not resolve a concrete type
var xx = :Zero;
^
Do this with a very general pre/post-order walking function.
Swift SVN r190
var func6 : ((int,int) -> int) -> (); // Takes a function, returns nothing.
func funcdecl5() {
func6(_0 + _1); // Closure with two named anonymous arguments
}
into:
(apply_expr type='()'
(declref_expr type='(int, int) -> int -> ()' decl=func6)
(closure_expr type='(int, int) -> int'
(anondecl '_0' type='int')
(anondecl '_1' type='int')
(tuple_expr type='int'
(binary_expr '+' type='int'
(declref_expr type='int' decl=_0)
(declref_expr type='int' decl=_1))))))))
However, there are still some problems with this (and we're definitely not doing type inference yet, all anon args are assumed 'int').
Swift SVN r111
var closure1 : () -> int = 4; // Function producing 4 whenever it is called.
var closure2 : (int,int) -> int = 4; // Has some (dead) arguments.
into:
(vardecl 'closure1' type='() -> int'
(closure_expr type='() -> int'
(integer_literal type='int' value=4)))
(vardecl 'closure2' type='(int, int) -> int'
(closure_expr type='(int, int) -> int'
(integer_literal type='int' value=4)))
Swift SVN r101
