Right now this is just an extra layer of indirection for the decls,
operators, and imports in a TU, but it's the first step towards compiling
multiple source files at once without pretending they're all in a single
file. This is important for the "implicit visibility" feature, where
declarations from other source files in the same module are accessible
from the file currently being compiled.
Swift SVN r9072
Pull the implicit 'Self' associated type out of the protocol and into
an implicitly-declared generic parameter list for the protocol. This
makes all of the methods of a protocol polymorphic, e.g., given
protocol P {
typealias Assoc
func getAssoc() -> Assoc
}
the type of P.getAssoc is:
<Self : P> (self : @inout P) -> () -> Self.Assoc
This directly expresses the notion that protocol methods are
polymorphic, even though 'Self' is always implicitly bound. It can be
used to simplify IRgen and some parts of the type checker, as well as
laying more of the groundwork for default definitions within
protocols as well as sundry other improvements to the generics
system.
There are a number of moving parts that needed to be updated in tandem
for this. In no particular order:
- Protocols always get an implicit generic parameter list, with a
single generic parameter 'Self' that conforms to the protocol itself.
- The 'Self' archetype type now knows which protocol it is
associated with (since we can no longer point it at the Self
associated type declaration).
- Protocol methods now get interface types (i.e., canonicalizable
dependent function types).
- The "all archetypes" list for a polymorphic function type does not
include the Self archetype nor its nested types, because they are
handled implicitly. This avoids the need to rework IRGen's handling
of archetypes for now.
- When (de-)serializing a XREF for a function type that has an
interface type, use the canonicalized interface type, which can be
meaningfully compared during deserialization (unlike the
PolymorphicFunctionType we'd otherwise be dealing with).
- Added a SIL-specific type attribute @sil_self, which extracts the
'Self' archetype of a protocol, because we can no longer refer to
the associated type "P.Self".
Swift SVN r9066
Semantic context describes the origin of the declaration and serves the same
purpose as opaque numeric "priority" in Clang -- to determine the most likely
completion.
This is the initial implementation. There are a few opportunities to bump the
priority of a certain decl by giving it SemanticContextKind::ExprSpecific
context that are not implemented yet.
Swift SVN r9052
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
