(Note that this registry isn't fully enabled yet; it's built so that
we can test it, but has not yet taken over the primary task of
managing conformances from the existing system).
The conformance registry tracks all of the protocols to which a
particular nominal type conforms, including those for which
conformance was explicitly specified, implied by other explicit
conformances, inherited from a superclass, or synthesized by the
implementation.
The conformance registry is a lazily-built data structure designed for
multi-file support (which has been a problematic area for protocol
conformances). It allows one to query for the conformances of a type
to a particular protocol, enumerate all protocols to which a type
conforms, and enumerate all of the conformances that are associated
with a particular declaration context (important to eliminate
duplicated witness tables).
The conformance registry diagnoses conflicts and ambiguities among
different conformances of the same type to the same protocol. There
are three common cases where we'll see a diagnostic:
1) Redundant explicit conformance of a type to a protocol:
protocol P { }
struct X : P { }
extension X : P { } // error: redundant explicit conformance
2) Explicit conformance to a protocol that collides with an inherited
conformance:
protocol P { }
class Super : P { }
class Sub : Super, P { } // error: redundant explicit conformance
3) Ambiguous placement of an implied conformance:
protocol P1 { }
protocol P2 : P1 { }
protocol P3 : P1 { }
struct Y { }
extension Y : P2 { }
extension Y : P3 { } // error: ambiguous implied conformance to 'P1'
This happens when two different explicit conformances (here, P2 and
P3) placed on different declarations (e.g., two extensions, or the
original definition and other extension) both imply the same
conformance (P1), and neither of the explicit conformances imply
each other. We require the user to explicitly specify the ambiguous
conformance to break the ambiguity and associate the witness table
with a specific context.
Swift SVN r26067
This commit validates @availability() attribute version ranges to ensure that
a declaration is not more available than its lexically containing scope. To do so,
we find the inner-most declaration containing an @availability attribute that itself
has an @availability attribute and check that first attribute's available
version range is contained in the enclosing declaration's available range. If not,
we emit a diagnostic.
This commit removes a FIXME for checking @availability and overrides. It appears that
the FIXME is a copy/paste to/from AttributeOverrideChecker, where it still resides.
Swift SVN r25453
Local type declarations are saved in the source file during parsing,
now serialized as decls. Some of these may be defined in DeclContexts
which aren't Decls and previously weren't serialized. Create four new
record kinds:
* PatternBindingInitializer
* DefaultArgumentInitializer
* AbstractClosureExpr
* TopLevelCodeDecl
These new records are used to only preserve enough information for
remangling in the debugger, and parental context relationships.
Finally, provide a lookup API in the module to search by mangled name.
With the new remangling API, the debugging lifecycle for local types
should be complete.
The extra LOCAL_CONTEXT record will compressed back down in a
subsequent patch.
Swift SVN r24739
Changing the design of this to maintain more local context
information and changing the lookup API.
This reverts commit 4f2ff1819064dc61c20e31c7c308ae6b3e6615d0.
Swift SVN r24432
rdar://problem/18295292
Locally scoped type declarations were previously not serialized into the
module, which meant that the debugger couldn't reason about the
structure of instances of those types.
Introduce a new mangling for local types:
[file basename MD5][counter][identifier]
This allows the demangle node's data to be used directly for lookup
without having to backtrack in the debugger.
Local decls are now serialized into a LOCAL_TYPE_DECLS table in the
module, which acts as the backing hash table for looking up
[file basename MD5][counter][identifier] -> DeclID mappings.
New tests:
* swift-ide-test mode for testing the demangle/lookup/mangle lifecycle
of a module that contains local decls
* mangling
* module merging with local decls
Swift SVN r24426
"private" is a very overloaded term already. "Cascading" instead of
"non-private" is a bit more clear about what will happen with this sort
of lookup.
No functionality change. There are some double negatives I plan to clean
up in the next commit, but this one was supposed to be very mechanical.
Swift SVN r23969
This adds a check to isPrivateContextForLookup, and also changes Sema to
use a function itself as the lookup context for non-generic functions'
result types (like generic functions already do). It also moves
isPrivateContextForLookup onto DeclContext itself, to be used in the next
commits.
Swift SVN r23633
Now that there's just one entry point for discriminated lookup, there's not
really a need for this extra abstraction.
One thing still up in the air is unqualified lookup support for discriminator
preferences (for, say, breakpoint conditions), but we'll cross that bridge
when we come to it.
Part of rdar://problem/17632175
Swift SVN r21755
Currently this only handles top-level nominal types. We're just trying to
emulate what the debugger does when it needs to go from a mangled name to
an AST node, so it's okay that the cases handled here are very restricted.
We just want to make sure that the debugger is /able/ to do what it needs
to do.
This does not yet handle nested (non-top-level) values; that will require
changes to DeclContext::lookupQualified.
Part of rdar://problem/17632175
Swift SVN r21690
This is in preparation for allowing demangling to match up with a particular
AST node, even if there are two private decls with the same name in the same
module. This commit doesn't actually change anything about the lookup; the
next commits will start adding support for the various lookups-with-
discriminators. (This is mostly only useful for the debugger.)
Part of rdar://problem/17632175
Swift SVN r21689
The issue here is that SILGen is expecting the argument pattern for the
synthesized ConstructorDecl to line up with the stored property list for the
decl containing the constructor. This is super fragile and probably the wrong
way to go (it would be better for sema to synthesize the entire ctor and make it
not be magical at all in silgen), but do a small fix to improve the situation
by inserting the lazy property storage next to the computed lazy property.
Swift SVN r19642
This just means we haven't deserialized them properly yet. As soon as we
try to /do/ something with the conformance, we'd pull in what we need, but
for reserializing (i.e. module-merging) we can generally just keep going.
<rdar://problem/17251682>
Swift SVN r19540
which will consolidate a bunch of places that this is used.
I'd appreciate review on this, because I can never keep getDeclaredTypeOfContext
vs getDeclaredTypeInContext straight.
Swift SVN r17891
The use of ASTContext-allocated arrays to store the members of nominal
type declarations and the extensions thereof is an
abomination. Instead, introduce the notion of an "iterable"
declaration context, which keeps track of the declarations within that
context (stored as a singly-linked list) and allows iteration over
them. When a member is added, it will also make sure that the member
goes into the lookup table for its context immediately.
This eliminates a ton of wasted memory when we have to reallocate the
members arrays for types and extensions, and moves us toward a much
more sane model. The only functionality change here is that the Clang
importer no longer puts subscript declarations into the wrong class,
nor does it nested a C struct within another C struct.
Swift SVN r16572
(This could occur, for instance, via a forward reference to a member defined in an extension to a generic type.) This problem has been popping up a lot lately, and
was making some of the recent runtime work difficult. (rdar://problem/16481483)
Swift SVN r15805
Make the name lookup interfaces all take DeclNames instead of identifiers, and update the lookup caches of the various file units to index their members by both compound name and simple name. Serialized modules are keyed by identifiers, so as a transitional hack, do simple name lookup then filter the results by compound name.
Swift SVN r14768
Change GenericFunctionType to reference a GenericSignature instead of containing its generic parameters and requirements in-line, and clean up some interface type APIs that awkwardly returned ArrayRef pairs to instead return GenericSignatures instead.
Swift SVN r13807
getInterfaceSelfType, inline them into their caller. This
has the nice effect of moving getSelfTypeForContainer into
Decl.cpp instead of being in DeclContext.cpp (which never
made sense to me).
Swift SVN r12984
To get here, make the implicit 'self' parameter a bit more like a
parsed parameter, by giving it a trivial TypeRepr so that pattern
validation will validate the type. This latter piece is important for
DynamicSelf, because we need the interface type of the function to
refer to the implicit generic parameter while the actual type refers
to the archetype.
Swift SVN r12757
1) Revert my change to give DeclContext a dump method, it confuses the debugger.
2) Refactor SILGen::requiresObjCPropertyEntryPoints out to
VarDecl::usesObjCGetterAndSetter.
Swift SVN r12526
This removes an oddity in the AST whereby the 'self' declaration
within a value type constructor was not represented as @inout, despite
having @inout semantics in the language.
Swift SVN r11194
getInterfaceSelfType gets the interface type of a 'self' parameter outside of the context, like getSelfTypeInContext does for the in-context self type.
getDeclaredInterfaceType gives the declared interface type of a TypeDecl.
getGenericSignatureOfContext returns the dependent generic signature of a decl context.
Swift SVN r10973
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
Qualified lookup depends not only on the current module but actually the
current file, since imports are file-scoped by default. Currently this only
affects lookup into other modules (e.g. "Foundation.NSString"), but this
could also be used for extension filtering.
This breaks one name resolution test, but the refactoring in the next
commit changes everything anyway and will restore the test.
Swift SVN r10831
The goal of this series of commits is to allow the main module to consist
of both source files and AST files, where the AST files represent files
that were already built and don't need to be rebuilt, or of Swift source
files and imported Clang headers that share a module (because they are in
the same target).
Currently modules are divided into different kinds, and that defines how
decls are looked up, how imports are managed, etc. In order to achieve the
goal above, that polymorphism should be pushed down to the individual units
within a module, so that instead of TranslationUnit, BuiltinModule,
SerializedModule, and ClangModule, we have SourceFile, BuiltinUnit,
SerializedFile, and ClangUnit. (Better names welcome.) At that point we can
hopefully collapse TranslationUnit into Module and make Module non-polymorphic.
This commit makes SourceFile the subclass of an abstract FileUnit, and
makes TranslationUnit hold an array of FileUnits instead of SourceFiles.
To demonstrate that this is actually working, the Builtin module has also
been converted to FileUnit: it is now a TranslationUnit containing a single
BuiltinUnit.
Swift SVN r10830
innermost DeclContext of the decl that uses the archetype instead of the
actual generic context of the archetype.
<rdar://problem/15453889> Qualified archetypes mangle wrong DeclCtx
Swift SVN r10470
And, properly treat imports as per-file: when looking up decls through the
TU module, don't pick up every other source file's imports.
This implements our resolution rules:
1. Check the current source file.
2. Check the current module.
3. Check imported modules.
Currently, "import Foo" is treated as a file-private import and
"@reexported import Foo" is treated as a public /and/ module-wide import.
This further suggests that access control is the right tool for re-export
control:
(private) import Foo // current file only
package import Foo // whole module
public import Foo // whole world
Swift SVN r9682
