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
Sub-patterns are now considered part of the enclosing pattern, so if the
parent pattern pointer is const, the child pointer will be too.
I changed the minimal number of files to make this work, but future code
should use "const Pattern *" when intended, and "Pattern *" only if they
intend to modify the pattern.
Swift SVN r5743
Just refer to "class archetypes" and "class protocols". Change 'isClassBounded' methods to 'requiresClass', which is a character shorter.
Swift SVN r5674
Reject attempts by non-class types to conform to class-bound protocols, whether bound directly by a [class_protocol] attribute or indirectly by refining a class-bound protocol.
Swift SVN r5552
This replaces the obscure, inefficient lookup into extensions with
something more straightforward: walk all of the known extensions
(available as a simple list), then eliminate any declarations that
have been shadowed by other declarations. The shadowing rules still
need to consider the module re-export DAG, but we'll leave that for
later.
As part of this, keep track of the last time we loaded extensions for
a given nominal type. If the list of extensions is out-of-date with
respect to the global generation count (which tracks resolved module
imports), ask the modules to load any additional extensions. Only the
Clang module importer can currently load extensions in this manner.
Swift SVN r5223
Most of this is mechanical, because we weren't actually relying on
byref(heap) for anything. Simplify capture analysis, now that the only
way a variable can have non-fixed lifetime is if it is actually
captured. Fixes <rdar://problem/11247831>.
Swift SVN r5046
Previously, the Clang importer would synthesize the memberwise
constructor itself, but not a default constructor. Eliminate the
redundant code path and provide correct semantics for the second by
letting the type checker introduce the implicitly-defined constructors
itself.
Swift SVN r4973
Report the decl context's location as the source location of a constructor if its body BraceStmt doesn't have a real source location, like we do for the elementwise constructor.
Swift SVN r4876
Rather than unconditionally introducing a memberwise constructor into
a struct, only introduce the implicit memberwise constructor if there
are not user-declared constructors within the struct declaration
itself. In other words, writing a constructor in the struct definition
takes over all of the constructors.
Swift SVN r4867
