Clean up the "can be accessed by dynamic lookup" predicate so that it
checks for a generic context. We no longer need to do the checking in
name lookup, since this means that the dynamic lookup table won't have
anything we can't use (thanks Jordan!). Drop the [objc] allowance for
members of a generic context: it still leaves us with a very weird
case of messaging something when we can't even figure out the type
that we think the object has.
Extend the walk searching for members to include inner classes within
structs, so we get all of the members globally.
Swift SVN r7799
We only know the type of functions and vars at the time we create them,
and sometimes not even those. Just use setType() in those constructors
and make all other ValueDecls simpler.
Swift SVN r7756
Unlike normal overload resolution, where we always want the
most-specialized, overriding result, overload resolution for dynamic
lookups favors results in superclasses to those in subclasses, because
we want to put the least requirements on the object
type. Additionally, we don't allow overload resolution to select among
results that come from different classes or protocols.
Swift SVN r7743
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
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
Break cycles agressively when we find circular class inheritance. The
stronger AST invariants prevent us from having to check for loops
everywhere in the front end.
Swift SVN r7325
First, make it actually check for cycles properly. Second, pull it
into the checking of the protocol itself, rather than keeping it as a
separate pass that happens too late to be useful. Finally, put the
unchecked/checking/checked bits into the AST to avoid having to keep a
separate DenseMap just for this purpose. Fixes <rdar://problem/14750346>.
Swift SVN r7324
This doesn't do anything yet, but will be used to record which decls
conform to these protocols when serializing a module.
This introduces a new metaprogramming file, KnownProtocols.def.
Swift SVN r7263
Turn NominalType::FieldRange into a more general template that can filter by any member decl type and predicate. Use an instance of it in UnionDecl::getAllElements to iterate through all its contained UnionElementDecls.
Swift SVN r7218
As discussed, this is an interim syntax for re-exports:
import [exported] Foundation
In the long run, we're probably going to use the same syntax as access
control for this, but that hasn't been designed yet.
Swift SVN r7050
Again, the import kind rules are:
- 'import KIND' can import any decl whose introducer is KIND.
- 'import typealias' can also import a struct, class, or union.
- Conversely, 'import KIND' can import a typealias for a decl whose
introducer is KIND.
- Only functions can be overloaded; anything else counts as an ambiguous
import and is an error.
- If an import statement only imports a single decl, but the user got the
kind wrong, we can issue a fix-it for the kind.
We don't have source locations or synthetic source for declarations yet,
so there are no notes about what's /causing/ the ambiguities. Tracked by
<rdar://problem/14650883>
Swift SVN r6917
Build a switch_union instruction over all the matched union elements, and check for exhaustiveness to see if we need to emit a default branch either for subsequent matches or to fall off the end and emit unreachable if we run out of cases.
Swift SVN r6870
This makes it very clean to reason about which part should be used
to find a module to load, and which part should be used to filter
lookup within that module.
This breaks the old "import swift.print" syntax in favor of the new
"import func swift.print", but the new syntax is currently ignored.
Swift SVN r6849
Also, update LangRef.
Note that an explicit "import module" has been left out for now, since
it's not strictly necessary and "module" isn't a keyword yet.
Swift SVN r6786
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
Now that we have true serialized modules, the standard library can import
the Builtin module without any special direction (beyond -parse-stdlib),
and anyone can include those modules without special direction.
Swift SVN r6752
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
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
This eliminates the duplicate IdentifierType resolution code (fixing
<rdar://problem/13946567>), and moves us a step closure to elimining
name binding as a separate pass.
Swift SVN r5940
Previously, this set of protocols was computed lazily, which fails
catastrophically if getProtocols() was invoked before validation of
the types in a type/extension's "inherited" list.
Swift SVN r5924
The lookup table for a nominal type declaration provides efficient
(O(1)) access to all of the declarations with a given name in a
nominal type and its extensions. This is architecturally different
from Clang's handling of Objective-C classes and
categories/extensions, where each category/extension has its own
lookup table, and is meant to reduce the number of hash table lookups
required, especially once these hash tables are stored in the module.
The lookup table is built and updated lazily as extensions and members
are introduced, similarly to Clang's lookup tables. However, the
simpler name lookup rules in Swift (vs. C/C++/Objective-C) make this
approach actually semantically correct.
Swift SVN r5874
This causes the SourceLoader to recursively parse the imported module in standard
library mode, giving it access to the Builtin module.
This is all a terrible hack and should be ripped out with great victory someday, but
until we have binary modules that persist the build setting used to produce the
module, this is the best we can do.
Swift SVN r5847
