When performing member lookup into an existential that involves the
DynamicLookup protocol, look into all classes and protocols for that
member. References to anything found via this lookup mechanism are
returned as instances of Optional.
This introduces the basic lookup mechanics into the type
checker. There are still numerous issues to work through:
- Subscripting isn't supported yet
- There's no SILGen or IRGen support
- The ASTs probably aren't good enough for the above anyway
- References to generics will be broken
- Ambiguity resolution or non-resolution
Thanks to Jordan for the patch wiring up DynamicLookup.
Swift SVN r7689
Each nested archetype X.Y corresponds to an associated type named 'Y'
within one of the protocols to which X conforms. Record the associated
type within the archetype itself. When performing type substitutions,
use that associated type to extract the corresponding type witness
rather than looking for the type itself. This is technically more
correct (since we used the type witness for type checking), and a step
toward pulling type substitutions into the AST.
Swift SVN r7624
We previously relied on the type checker to fill in the implementation
types (swift.Slice<T> and swift.Optional<T>, respectively), which
limited our ability to perform type transformations in the AST. Now,
the AST knows how to form these implementation types on demand.
Swift SVN r7587
In Swift, a module is expected to know which libraries it needs, rather than
having this specified by an external module map. While we haven't quite
designed this yet (frameworks get this for free in Clang, for example),
we can at least provide a simple option for the common case of a module
associated with a single library.
This will probably change in the future, so I left in the more general
deserialization code I was working on before simplifying the use case.
A loaded module can in theory specify any arbitrary frameworks or libraries
as dependencies, not just a single dylib.
Swift SVN r7583
This breaks the type-canonicalization link between a generic parameter
type and the archetype to which it maps. Generic type parameter types
are now separate entities (that can eventually be canonicalized) from
archetypes (rather than just being sugar).
Most of the front end still traffics in archetypes. As a step away
from this, allow us to type-check the generic parameter list's types
prior to wiring the generic type parameter declarations to archetypes,
using the new "dependent" member type to describe assocaited
types. The archetype builder understands dependent member types and
uses them to map down to associated types when building archetypes.
Once we have assigned archetypes, we revert the dependent identifier
types within the generic parameter list to an un-type-checked state
and do the type checking again in the presence of archetypes, so that
nothing beyond the generic-parameter-list checking code has to deal
with dependent types. We'll creep support out to other dependent types
elsewhere over time.
Swift SVN r7462
Previously, we were creating the type corresponding to
class/struct/union declarations as part of creating the declaration
node, which happens at parse time. The main problem with this (at the
moment) occurs with nested nominal types, where we'd end up with the
wrong "parent" type when the type was nested inside an extension
(because the extension hadn't been resolved at the time we accessed
the parent's type). Amusingly, only code completion observed this,
because the canonical type system hid the problem. The churn in the
code-completion tests come from the fact that we now have the proper
declared type for class/struct/union declarations within extensions.
Take a step toward order-independent type checking by setting the type
of a class/struct/union declaration in type checking when we either
find the declaration (e.g., due to name lookup) or walk to the
declaration (in our walk of the whole translation unit to type-check
it), extending the existing TypeChecker::validateTypeDecl() entry
point and adding a few more callers.
The removeShadowedDecls() hack is awful; this needs to move out to the
callers, which should be abstracted better in the type checker anyway.
Incremental, non-obvious step toward fixing the representation of
polymorphic function types. This yak has a *lot* of hair.
Swift SVN r7444
Another baby step toward a proper canonical form for polymorphic
function types: generic parameters will eventually be uniquable by
their depth and index.
Swift SVN r7380
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
...by adding a new callback to ModuleLoader: loadDeclsConformingTo.
This is used only when the type checker doesn't have enough contextual
information to resolve an expression involving a literal, so it's
possible many *LiteralConvertible types will never be loaded.
Deserialization of types with conversion methods is still eager, since
there's no easy hook to tell when they're needed, but the list has been
renamed to refer to any decls that need to be eagerly deserialized, in
case we need it for other purposes in the future.
This probably won't help much in a real program, but it cuts the test
run time by about 5-10% in my build.
Swift SVN r7268
This is really two commits in one: first, change the AST and TypeChecker
to only track conformances to known protocols, and second, make sure we
can deserialize decls that conform to known protocols on demand. The
latter is necessary for the type checker to solve constraint systems that
are not fully constrained, and also requires tracking decls with conversion
methods.
Currently decls conforming to known protocols are eagerly deserialized;
that will change soon to be a new ModuleLoader callback. Decls with
conversion functions will continue to be eagerly deserialized for the near
future.
This fixes the initial regressions in making decl deserialization lazy.
Swift SVN r7264
This also makes extension-loading slightly more precise; if asked to
load extensions for some struct Foo, we will load extensions for /every/
struct Foo...but now we won't /also/ load extensions for every /class/ Foo.
Swift SVN r7260
This switches from simple lists of decls to name-based on-disk hash tables,
which allows decls to be loaded lazily when doing simple lookup (but not
code completion, at least not yet).
The on-disk hash table implementation is borrowed from Clang; eventually
it will be pushed down to LLVM's Support library. (Fortunately the
implementation is header-only.)
This breaks a few tests that rely on magic protocols like
IntegerLiteralConvertible, because the type checker won't have seen the
types that conform to those protocols yet. This will be fixed by doing
an additional "hey, modules, got any of these?" lookup.
Swift SVN r7259
- New type representation OptionalTypeRepr.
- New sugared type OptionalType.
- New base type SyntaxSugarType, parent of ArraySliceType and OptionalType.
These two are the same in a lot of ways.
- The form "T[]?" is forbidden, because it makes "Int[4][2]" oddly
different from "Int[4]?[2]". The type can be spelled "(T[])?" or
Optional<T[]>.
- Like Slice, "Optional" is just looked up in the current module. This may
or may not be the desired behavior in the long run.
<rdar://problem/14666783>
Swift SVN r7100
Previously, a module contained references to every module listed in the
ASTContext. Now, we actually only encode the imports from the TU itself,
which allows us to include access paths for scoped imports.
This is necessary to implement proper name lookup shadowing rules.
Swift SVN r7013
The current implementation of dealloc_stack in IR-gen is a
no-op, but that's very much wrong for types with non-trivial
local allocation requirements, e.g. archetypes. So we need
to be able to do non-trivial code here. However, that means
modeling both the buffer pointer and the allocated address
in SIL.
To make this more type-safe, introduce a SIL-specific
'[local_storage] T' type that represents the required
allocation for locally storing a T. alloc_stack now returns
one of those in additon to a *T, and dealloc_stack expects
the former.
IR-gen still implements dealloc_stack as a no-op, but
that's now easy to fix.
Swift SVN r6937
Factor the ProtocolConformance class into a small hierarchy of
protocol conformances:
- "normal" conformance, which provides a complete mapping for the
explicit conformance of a nominal type (which may be generic) to a
protocol;
- "specialized" conformance, which specializes a generic
conformance by applying a set of substitutions; and
- "inherited" conformance, which projects the conformance from a
superclass to a conformance for a subclass.
In this scheme "normal" conformances are fairly heavyweight, because
they provide a complete mapping. Normal conformances are unique,
because they're associated with explicit conformance declarations
(which cannot be repeated within a module; checking is TBD). Thus, IR
generation will eventually emit them as strong symbols.
"Specialized" and "inherited" conformances occur when we're dealing
with generic specializations or subclasses. They project most of their
members through to some underlying conformance, eventually landing at
a "normal" conformance. ASTContext is responsible for uniquing these
conformances when it sees them. The IR generation model for
specialized conformances will involve runtime specialization of the
underlying witness table; inherited conformances are probably no-ops
from the IR generation perspective.
Aside from being the right thing to do, having small, uniqued
conformances for the specialization and inheritance cases is good for
compile-time performance and memory usage. We're not really taking
advantage of this everywhere we could, yet.
This change uncovered a few existing issues (one known, one not
known), particularly because we're projecting inherited conformances
rather than building new conformances:
- <rdar://problem/14620454>: protocol witnesses to methods of
classes need to perform dynamic dispatch. See the
test/Interpreter/typeof.swift test for an example.
- <rdar://problem/14637688>: comparing NSString and String with ==
fails, because they are inter-convertible. I suspect we were missing
some protocol conformances previously, and therefore accepting this
obviously-invalid code.
Swift SVN r6865
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 should include all of the attributes we care about for the time being.
Only the resilience attributes (not designed) and [force_inline] are left
unaccounted for.
Swift SVN r6767
This makes ProtocolConformances fully self-identifying so that a ProtocolConformance* pointer alone is enough to identify a conformance as a link entity.
We currently lose the conforming decl during deserialization because trying to deserialize a reference to an ExtensionDecl asserts out. I'll bug Jordan about that.
Swift SVN r6735
The 'inherited' type list of a declaration represents the parsed for
of the inheritance clause, which is now not serialized. The semantic
informance exists in the superclass (when present) and list of
protocols. Future refactoring of the 'inherited' list will make this
more clear.
Swift SVN r6686
Switch a few more clients from ::getInherited() to
::getProtocols(). The trajectory here is that ::getInherited() will
turn into something only populated when we've parsed the inheritance
clause, and that "the truth" will be getProtocols(). The former will
cease being serialized once this is the case.
Swift SVN r6661
Previously, we only tracked the mapping from associated types to their
type witnesses. Now, also track the protocol conformances for each of
the requirements placed on the associated types.
Swift SVN r6655
- Add the attribute to AnyFunctionType::ExtInfo.
- Propagate the attributes from DeclAttributes to AnyFunctionType for
FuncDecls in TypeCheckDecl.cpp.
- Make sure the new attribute is serialized.
The main missing pieces are checking the applicability of the type attributes
on the FuncDecl and teaching typechecker about conversions on types with
noreturn.
Swift SVN r6359
Elements of a tuple type now know if there is a default argument, and
what kind of default argument it is (callee side, __FILE__, __LINE__,
__COLUMN__), but they don't have an actual expression. There are a
number of cleanups this enables that will follow.
Note that the serialization support is as-yet-untested.
Swift SVN r6351
Generic parameters are implemented using specially-tagged TypeAliasDecls.
Unlike normal ValueDecls, their names are not resilient, and so cross-
module references shouldn't refer to them by name. Instead, use an index
into the generic parameter list of their context.
Since generic parameters can appear within extensions, this new kind isn't
mutually exclusive with the just-introduced ExtensionValue. Change that to
be a separate flag that applies to both Values and GenericParameters.
Swift SVN r6304
Previously, cross-references used a simple access path to refer to values
in other modules, but extensions have no name. They also accidentally
picked up values in extensions anyway, because lookupDirect includes
members in extensions. Now, we filter out values that don't come from
the referenced module, which may not be the same module the base type
comes from.
Swift SVN r6301
Teach TuplePatternElt to keep track of the kind of the default
argument: none, normal (provided by calling into the appropriate
callee generator), __FILE__, __LINE__, or __COLUMN__. For the latter
three cases, the type checker forms the appropriate argument as part
of the call.
The actual default argument expression will only be held in the tuple
pattern element when we've parsed it; it won't be serialized or
deserialized, because only the defining module cares. This is a step
toward eliminate the initialization expression from tuple types.
The extension to TupleShuffleExpr is a hack, which will also be
replicated in ScalarToTupleExpr, until we finally rework the
representation of TupleShuffleExpr (<rdar://problem/12340004>).
Swift SVN r6299
The semantics of varargs (only for the last element) make it more appropriate as a property of the TuplePattern.
Also free the Parser from needing to construct synthetic types (ArraySlice for type of vararg element) to
accommodate the TypeChecker and move the logic to the TypeChecker. This will be more beneficial when the parser stops
creating types in general.
Swift SVN r6271
Give oneof bodies syntax consistent with other NominalTypes. Give oneof elements first-class declaration syntax using the 'case' introducer, as suggested by Jordan. Oneofs can contain 'case' decls, functions, properties, and constructors, but not physical ivars. Non-oneof scopes cannot contain 'case' decls. Add some QoI to the oneof 'case' parser to also parse and complain about things that resemble switch 'case' labels inside decl contexts.
Swift SVN r6211
I had previously thought these didn't appear in public decls, but they're
used when you extend a generic class without generic arguments.
Swift SVN r6187
Currently, we are eagerly deserializing extensions. This probably isn't
what we want to do in the long run, but until lookup settles down a bit
it's not worth optimizing.
Swift SVN r6186
Take advantage of the fact that a function can never be both a conversion
method and an assignment operator to pack both flags into the same bit in
the serialized record.
Swift SVN r6185
For consistency purposes, VarDecls in the subscript pattern now have the
enclosing nominal as their decl context, rather than no decl context at all.
Swift SVN r6177
