After 7400d484 we tried to walk into enum elements, but forgot to check
for missing types (which caused an assertion in getType) or element
decls (which caused an assertion or crash inside passReference).
rdar://problem/24634223
When one spells a compound declaration name in the source (e.g.,
insertSubview(_:aboveSubview:), keep track of the locations of the
base name, parentheses, and argument labels.
When users try to print the interface of a specific type (most often through cursor
infor query of SourceKit), we should simplify the original decls by replacing
archetypes with instantiated types, hiding extension details, and omitting
unfulfilled extension requirements. So the users can get the straight-to-the-point
"type interface". This commit builds the testing infrastructure for this feature,
and implements the first trick that wraps extension contents into the interface body.
This commit also moves some generic testing support from SourceKit to Swift.
Swift SVN r32630
With this change, TypeReprs no longer contain fully-resolved types for
any parsed code. Rather, they contain unresolved identifiers or the
declarations to which the identifiers have resolved.
As a minor space optimization, collapse the unbound (Identifier)
representation and the bound (ValueDecl *) representation into a
single pointer union.
Swift SVN r32434
Having bound types in TypeReprs causes trouble in several places
(mostly involving type-checking of generics), and doesn't really fit
with TypeReprs being a mostly syntactic construct. Eliminate some code
paths using getBoundType(), and make the others do the same thing for
getBoundDecl() and getBoundType(). As part of the latter, provide
TypeBase::getDirectlyReferencedTypeDecl() to more easily map from type
to the named declaration.
Swift SVN r32018
When SourceEntityWalker visits a subscript reference it sometimes needed to visit
both open and close brackets. It used to be implemented as two calls to a regular
visitDeclReference which confused the clients expecting one call per a reference,
for example indexing was recording two references to a subscript.
We add a separate visitSubscriptReference to resolve this problem.
Swift SVN r31494
This returns to the behaviour we had before ModuleDecl came about. It
fixes an assertion in SourceKit concerning the kinds of decls we will
visit in visitDeclReference. As the comments indicate, we need this
special case until Swift supports first class submodules.
Swift SVN r28934
declarations generated by the type-checker.
Unfortunately, it's not possible to directly check this
because the verifier is itself based on ASTWalker. But I'm
going to add an assertion to SILGen in a follow-up that
assumes that TypeCheckError has visited every ApplyExpr,
and since SILGen already walks most of the AST with its
own custom walker, that will check this well enough.
Swift SVN r28732
Now that we don't have generic parameter lists at arbitrary positions
within the extended type of an extension declaration, simplify the
representation of the extended type down to a TypeLoc along with a
(compiler-synthesized) generic parameter list.
On the parsing side, just parse a type for the extended type, rather
than having a special grammar. We still reject anything that is not a
nominal type (of course), but it's simpler just to call it a type.
As a drive-by, fix the crasher when extending a type with module
qualification, rdar://problem/20900870.
Swift SVN r28469
Make unqualified lookup always provide a declaration for the things it
finds, rather than providing either a module or a declaration. Unify
various code paths in our type checker now that module declarations
come in with the other declarations.
Swift SVN r28286
The eventual goal for extensions of generic types is to require them
to specify their generic parameters, e.g.,
extension Array<T> { ... }
rather than today's
extension Array { ... }
Start parsing (optional) generic parameters here, and update the
representation of ExtensionDecl to accomodate this new grammar
production. Aside from the parser changes, there's no intended
functionality change here.
Swift SVN r20682
This completes the FileUnit refactoring. A module consists of multiple
FileUnits, which provide decls from various file-like sources. I say
"file-like" because the Builtin module is implemented with a single
BuiltinUnit, and imported Clang modules are just a single FileUnit source
within a module.
Most modules, therefore, contain a single file unit; only the main module
will contain multiple source files (and eventually partial AST files).
The term "translation unit" has been scrubbed from the project. To refer
to the context of declarations outside of any other declarations, use
"top-level" or "module scope". To refer to a .swift file or its DeclContext,
use "source file". To refer to a single unit of compilation, use "module",
since the model is that an entire module will be compiled with a single
driver call. (It will still be possible to compile a single source file
through the direct-to-frontend interface, but only in the context of the
whole module.)
Swift SVN r10837
