This functionality doesn’t really change what we accept right now, because we eagerly import all of the methods of a class when we do *any* kind of lookup into the class. However, when we manage to stop doing that, this operation will become more important.
Swift SVN r23289
This performs very conservative dependency generation for each compile task
within a full compilation. Any source file, swiftmodule, or Objective-C
header file that is /touched/ gets added to the dependencies list, which
is written out on a per-input basis at the end of compilation.
This does /not/ handle dependencies for the aggregated swiftmodule, swiftdoc,
generated header, or linked binary. This is just the minimum needed to get
Xcode to recognize what needs to be rebuilt when a header or Swift source
file changes. We can revisit this later.
This finishes <rdar://problem/14899639> for now.
Swift SVN r18045
Also, create the Clang module loader directly rather than indirecting through
a "get constructor" function. It's no longer a valid configuration to not
have a Clang importer.
Swift SVN r16862
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
