Instead of relying on the subpattern being a well-formed TuplePattern, let's track our own subelements so we can associate them to properties and validate them ourselves.
Swift SVN r8771
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
There were two overloads of lookupVisibleDecls: one that performed
unqualified lookup from a particular decl context, the other performing
qualified lookup into a given type from a particular decl context.
They don't really behave the same, so let's give them different names.
Swift SVN r8641
and remove DeclContext base class from FuncDecl, ConstructorDecl and
DestructorDecl
This decreases the number of DeclContexts to 7 and allows us to apply
alignas(8) to DeclContext.
Swift SVN r8186
This was not likely an error-free change. Where you see problems
please correct them. This went through a fairly tedious audit
before committing, but comments might have been changed incorrectly,
not changed at all, etc.
Swift SVN r7631
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
This is a tradeoff, assuming that lookup in a particular module is less
likely to be repeated than lookup within the current source file. By
storing the cached results with the TU's own local lookup cache, the
results get cleared out when we parse additional decls.
Since this is only used by code completion, there's no performance benefit
for the compiler, or even for swift-ide-test...it's only in repeated lookups
that this will be useful.
Swift SVN r7169
This makes lookupVisibleDecls use the same code path as qualified and
unqualified lookup. This is more expensive, because it needs to actually
collect a list of /all/ decls in order to properly compute shadowing
information, but this list is not likely to change once the set of imports
has been computed, so we can cache it.
Swift SVN r7168
Note that the import kind is not checked yet; this is effectively our old
behavior for "import swift.print".
Infrastructure: move Module::forAllVisibleModules out-of-line, and add
makeStackLambda to STLExtras for using a non-escaping lambda with
std::function.
Swift SVN r6852
We haven't fully updated references to union cases, and enums still are not
their own thing yet, but "oneof" is gone. Long live "union"!
Swift SVN r6783
This iterates over a module's exports, transitively, in an unspecified
but deterministic order. This is useful for any sort of lookup and for
managing transitive inclusion. It also allows us to remove the hack in
Sema for loading a Clang module's adapter module, and just rely on the
previous commit.
Swift SVN r6699
This makes it very clear who is depending on special behavior at the
module level. Doing isa<ClangModule> now requires a header import; anything
more requires actually linking against the ClangImporter library.
If the current source file really can't import ClangModule.h, it can
still fall back to checking against the DeclContext's getContextKind()
(and indeed AST currently does in a few places).
Swift SVN r6695
Standardize on the more-common "superclass" and "subclass" terminology
throughout the compiler, rather than the odd mix of base/derived and
super/sub.
Also, have ClassDecl only store the Type of the superclass. Location
information will be part of the inheritance clause for parsed classes.
Swift SVN r6687
Rather than automatically re-exporting or not re-exporting every import in
a TranslationUnit, we'll eventually want to control which imports are local
(most of them) and which imports are shared with eventual module loaders.
It's probably not worth implementing this for TranslationUnit, but
LoadedModule can certainly do something here.
Currently, a LoadedModule is even more permissive than a TranslationUnit:
all imports are re-exported. We can lock down on this once we have a
re-export syntax.
Swift SVN r6523
This change also exposes and fixes a bug where we would improperly filter
shadowed declarations. removeShadowedDecls() assumed that all decls had the
same name, but when it is used from lookupVisibleDecls(), this is not true.
Thus, we group decls not only by signature, but also by name.
Swift SVN r6460
Removes the boolean IsTypeLookup and OnlyInstanceMembers, which were totally
misleading.
This fixes some bugs in lookupVisibleDecls, which allows us to remove
workarounds in code completion, that were not correct in some corner cases.
Now we also code complete references to instance functions in static contexts,
but code completion results in this case state the type of the resulting object
incorrectly.
Swift SVN r6396
This is a temporary hack until we properly make these carry
their own generic parameters.
This removes the last valid way to get UnboundGenericTypes in
a checked program.
Swift SVN r6373
for protocols when code completing outside the protocol's DeclContext on a
protocol's instance
'This' is obviously not allowed, but references to nested typealiases are
sometimes allowed on protocol instances, but only sometimes (filed
rdar://14489286). Just don't display such code completion results for now.
Swift SVN r6372
the containing DeclContext
Fixes a few FIXMEs in code completion where we were providing results that
refer to generic arguments outside of their scope.
Swift SVN r6370
is documented: look up members of a type that are visible from a specific
module. It does not matter much now, but when we have access control, it will.
Before this change, lookupVisibleDecls() tried to guess the *defining* module
of the type, and gave up if it could not. It forced us to duplicate some
lookup logic for some types (archetypes and protocol compositions). Also add a
test that lookup finds members of archetype's superclass, which the original
(duplicated) code did not handle.
Swift SVN r6363
need to unwrap the type sugar.
This was uncovered by the removal of IdentifierType and removal of
getCanonicalType() in code completion, which was working around
lookupVisibleDecls() not working for IdentifierTypes.
Swift SVN r6332
This lookup routine takes the place of MemberLookup for AST-level
lookups, which don't consider semantics at all and won't be able to
(for example) perform additional type checking to resolve the
lookup. No functionality change.
Swift SVN r5882
We decided to go with 'var' as a distributive pattern introducer which applies to bare identifiers within the subpattern. For example, 'var (a, b)' and '(var a, var b)' would be equivalent patterns. To model this, give 'var' its own AST node with a subpattern and remove the introducer loc from NamedPattern.
Swift SVN r5824
I talked to John about parsing patterns today, and because of the magnitude of name-lookup-dependent ambiguities between patterns and expressions, we agreed that at least for a first-pass implementation it makes sense to parse patterns as extensions of the expr grammar and charge name binding with distinguishing patterns from expressions. This gets us out of needing the concept of an "unresolved pattern", at least in the short term.
Swift SVN r5808
