Instead, pass a LazyResolver down through name lookup, and type-check
things on demand. Most of the churn here is simply passing that extra
LazyResolver parameter through.
This doesn't actually work yet; the later commits will fix this.
Swift SVN r8643
...unless the functions are declared [transparent], or if we're in an
immediate mode (in which case we won't get a separate chance to link
against the imported TUs).
This is an optimization that will matter more when we start dealing with
Xcode projects with many cross-file dependencies, especially if we have
some kind of implicit import of the other source files in the project.
In the future, we may want to parse more function bodies for the purpose
of inlining, not just the transparent ones, but we weren't taking
advantage of that now, so it's not a regression. (We're still not taking
advantage of it even for [transparent] functions.)
Swift SVN r7698
Now that we have true serialized modules, the standard library can import
the Builtin module without any special direction (beyond -parse-stdlib),
and anyone can include those modules without special direction.
Swift SVN r6752
This causes the SourceLoader to recursively parse the imported module in standard
library mode, giving it access to the Builtin module.
This is all a terrible hack and should be ripped out with great victory someday, but
until we have binary modules that persist the build setting used to produce the
module, this is the best we can do.
Swift SVN r5847
This replaces the obscure, inefficient lookup into extensions with
something more straightforward: walk all of the known extensions
(available as a simple list), then eliminate any declarations that
have been shadowed by other declarations. The shadowing rules still
need to consider the module re-export DAG, but we'll leave that for
later.
As part of this, keep track of the last time we loaded extensions for
a given nominal type. If the list of extensions is out-of-date with
respect to the global generation count (which tracks resolved module
imports), ask the modules to load any additional extensions. Only the
Clang module importer can currently load extensions in this manner.
Swift SVN r5223
This paves the way for having a Swift module importer. The eventual goal
here is to eliminate all explicit uses of the Clang module loader, but
I'm not going to push too hard on that for now.
Swift SVN r5092
just move the Sema code into the Parser library. There is no way to use one without
the other. The library formerly known as Sema will get renamed.
Swift SVN r542
oneof { T*, Absent, ParseError, SemaError }.
This replaces the former convention used by the expression parsing
logic that used NullablePtr + bool to indicate all of these states,
in a way that I could never keep straight.
This should lead to better error recovery, but needs to be adopted by
more parts of the parser. Sema still uses NullablePtr because it
either returns a valid AST node or has a semantic error, there is no
parse error possible in Sema.
Swift SVN r503
to func exprs. All the tests pass again. Now we have a strict equality
between:
func foo(a : int) -> int { a+1 }
and
var foo = func(a : int) -> int { a+1 }
except we don't support the later syntax yet. We also really need return, though
we're getting closer to being able to usefully support it.
Swift SVN r466
annoying things from the grammar (like expr-non-brace), and makes it so that
the body/else of an if is just a statement.
This patch has a fairly serious caveat that we just drop function bodies on the
floor now, since we have no "stmtexpr" sort of thing to represent the syntactic
sugar that is func. We'll fix that soon.
Swift SVN r462
where you can optionally declare a receiver type. This is cleaner both conceptually
and in implementation, and eliminates drug references. :)
Swift SVN r444
is no AST building or typechecking support yet. Document the intended
semantics in LangRef. This is clearly subject to change, but is a starting
point.
Swift SVN r393
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
#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
