Only use the existing type checker (via "TC") in the iterative type
checker when we're actually making use of its functionality. The
intent is to drive this usage down to zero as we port code over to the
iterative type checker, so unprincipled uses get in the way.
Swift SVN r32573
Put in some rudimentary logic for finding circular references within
the iterative type checker and diagnosing those cycles. The
"rudimentary" part is because we're performing linear searches within
a stack rather than keeping a proper dependency graph, which is
inefficient and could display longer cycles than are actually
present. Additionally, the diagnostic is not specialized to the actual
query, so we get a generic "circular reference" diagnostic. OTOH, we
show all of the declarations involved in the cycle, which at least
lets the user figure out where the cycle occurred.
Enable the iterative type checker for resolving the type of a global
typealiases.
Swift SVN r32572
Introduce a request kind for resolving a TypeRepr, and teach type
resolution the start of performing "structural" resolution of a
TypeRepr that gets the basic structure (e.g., we're pointing at
something that is a nominal type, etc.) without checking its
semantics, dealing with generic arguments, etc.
None of this is active yet.
Swift SVN r32569
Start threading an (optional) UnsatisfiedDependency callback through type resolution, poke it when we're going to perform name lookup on a particular name.
As part of this, teach type resolution to distinguish between "early return due to unsatisfied dependencies" and "early return due to error", and not to mark type representations as invalid while failing.
This is all inactive code.
Swift SVN r32567
The separate "enumerate dependencies" and "satisfy" phases didn't make
sense, because one often needs to process part of a request to enumerate
additional dependencies. Collapse these two phases into a single
"process" operation that makes what progress it can, and enumerates
additional dependencies that need to be satisfied before it can
progress further.
Swift SVN r32563
Implement some awful, *recursive* code in the *iterative* type checker
that satisfies all of the dependencies of a type check request
(*recursively*) before satisfying the type check request itself. This
is placeholder code that lets us flesh out the dependency mechanism
separately from implementing the proper data structures.
To test this, implement a type check request for type-checking one
type within an inheritance clause. Make the superclass type check
request depend on the first type in the inheritance clause of the
class, with a recovery path that looks at subsequent types in the
inheritance clause so long as we're still seeing protocol types. This
checking is more minimal than what we were doing previously (where we
would check all of the inherited types to find the superclass) and a
simple illustration of dependencies that can evolve.
Swift SVN r32559
This is all effectively NFC, but lays out the shape of the iterative
type checker: requests are packaged up in TypeCheckRequest, we can
check whether the request has been satisfied already (isSatisfied),
enumerate its dependencies (enumerateDependenciesOf) in terms of other
TypeCheckRequests, and satisfy a request (satisfy).
Lazily-computed semantic information is captured directly in the
AST, but has been set aside in its own structure to allow us to
experiment with moving it into a lookaside table.
The only request that exists now is to type-check the superclass of
the given class. It currently performs unhealthy recursion into the
existing type checker. As we detangle dependencies, this recursion
between the IterativeTypeChecker and the TypeChecker can go away.
Swift SVN r32558
Now we can handle simple cases like
1 + 1 == 2 <here>
and correctly suggest both + on the 2 and || on the boolean. When the
LHS doesn't type-check we fallback to using only the operand immediately
to the left.
Swift SVN r32489
This allows us to start code-completing infix operators in postfix
expressions. As a first step, this patch only handles completing
against the immediate LHS (so for example 1 == 1 <here> doesn't suggest
boolean operators yet).
The next step is to feed the leading sequence expression from the parser
in so we can consider how the operator being completed fits into the
whole sequence expression.
For rdar://problem/22460167
Swift SVN r32465
When completing type members, teach the code completion engine to
transform the archetypes appearing in code completion results to the
actual types. NFC
Swift SVN r31628
When users complete the right-hand side of an assignment expression, we only
show the results whose types are convertible to those of the left-hand side.
Swift SVN r31357
Before this commit, for unresolved members, code completion suggests all visible enum elements
and option set types. To refine the results, this commit uses constraint solver to infer
the type of unresolved members by analyzing parental expressions. If the solver has solutions,
we complete the unresolved member, otherwise abort.
rdar://16659653
Swift SVN r31195
We were asserting (and doing the wrong thing) when trying to code
complete
nil #^HERE^#
The issue is that we tried to apply a solution to the expression that
contained free type variables (converted to generic parameters). This
trips us up when we expect the new type to conform to protocols. In code
completion we generally only need the type of the expression, so this
commit switches to getting that more explicitly. That said, this did
cause us to drop non-API parameter names in call patterns after an
opening '(' in some cases (covered by rdar://20962472).
Thanks to Doug for suggesting this solution!
rdar://problem/20891867
Swift SVN r28584
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
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
