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
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
-Refactor Parser to stop creating types
-Refactor TypeChecker to create types by resolving TypeReprs.
-Remove "validation" bit from the type system.
We don't need to "validate" every type that gets created but there's still a validation bit in TypeLoc,
necessary because of generic substitutions.
Swift SVN r6326
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
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
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
This lookup routine takes the place of MemberLookup for AST-level
lookups, which don't consider semantics at all and won't be able to
(for example) perform additional type checking to resolve the
lookup. No functionality change.
Swift SVN r5882
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
Introduce Pattern subclasses for the 'is T', 'T(<pattern>)', and '<expr>' pattern syntaxes we'll be introducing for pattern-matching "switch" statements. Also add an 'UnresolvedCalLPattern' to act as an intermediate for name lookup to resolve to a nominal type, oneof element, or function call expression pattern. Since we'll need to be able to rewrite patterns like we do expressions, add setters to AST nodes that contain references to subpatterns. Implement some basic walking logic in places we search patterns for var decls, but punt on any more complex type-checking or SILGen derived from these nodes until we actually use them.
Swift SVN r5780
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
When type-checking explicit protocol conformances for a type or extension, save the ProtocolConformance mappings from that declaration in the decl node. We'll need this in order to emit ObjC protocol conformances, which can't be emitted internally on-demand the way we currently emit Swift protocol witness tables. No functionality change.
Swift SVN r5632
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
Creating forwarding substitutions is straightforward enough that we don't need to fudge them in the AST, so remove the forwarding substitutions from ConstructorDecl and construct them instead on the fly in SILGen. We're going to need to be able to forward archetypes in other places in SILGen, such as when emitting closures or curried thunks in generic contexts. No functionality change.
Swift SVN r5418
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
This commit implements closure syntax that places the (optional)
parameter list in pipes within the curly braces of a closure. This
syntax "slides" well from very simple closures with anonymous
arguments, e.g.,
sort(array, {$1 > $0})
to naming the arguments
sort(array, {|x, y| x > y})
to adding a return type and/or parameter types
sort(array, {|x : String, y : String| -> Bool x > y})
and with multiple statements in the body:
sort(array, {|x, y|
print("Comparing \(x) and \(y)\n")
return x > y
})
When the body contains only a single expression, that expression
participates in type inference with its enclosing expression, which
allows one to type-check, e.g.,
map(strings, {|x| x.toUpper()})
without context. If one has multiple statements, however, one will
need to provide additional type information either with context
strings = map(strings, {
return $0.toUpper()
})
or via annotations
map(strings, {|x| -> String
return x.toUpper()
}
because we don't perform inter-statement type inference.
The new closure expressions are only available with the new type
checker, where they completely displace the existing { $0 + $1 }
anonymous closures. 'func' expressions remain unchanged.
The tiny test changes (in SIL output and the constraint-checker test)
are due to the PipeClosureExpr AST storing anonymous closure arguments
($0, $1, etc.) within a pattern in the AST. It's far cleaner to
implement this way.
The testing here is still fairly light. In particular, we need better
testing of parser recovery, name lookup for closures with local types,
more deduction scenarios, and multi-statement closures (which don't
get exercised beyond the unit tests).
Swift SVN r5169
When opening generic types, only the type variables for the primary archetypes become syntactic parameters of the BoundGenericType. We still open the associated archetypes; we just don't add them as arguments.
Swift SVN r5052
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
During type checking, fake up a "forwarding" substitution set for constructor decls that maps archetypes to themselves. This is goofy, but type-checking is the place that knows how to make ProtocolConformances, and I don't want to reinvent that. Use these forwarding substitutions in SILGen when emitting a generic allocating constructor so we can properly emit a call to the corresponding initializing constructor.
Swift SVN r4684
This nests top level PatternBindingDecls (in "main modules") under TopLevelCodeDecls,
instead of having them live in a translation unit. They contain code that is executed,
so they should be in a TLCD.
Swift SVN r4668
This gives us a couple things:
- It lets name binding match up operator funcs to operator decls reliably without depending on unary operators being properly attributed;
- It allows unary operators on tuples to be distinguished from binary operators; the former should always be declared 'func +(_:(x:A,y:B))', and the latter as 'func +(x:A,y:B)'.
Swift SVN r4636
During name binding, associate func decls with operator decls. When parsing SequenceExprs, look up operator decls to determine associativity and precedence of infix operators. Remove the infix_left and infix_left attributes, and make the infix attribute a simple declared attribute [infix] with no precedence.
Operator decls are resolved as follows:
- If an operator is declared in the same module as the use, resolve to the declaration in the current module.
- Otherwise, import operator declarations from all imported modules. If more than one declaration is imported for the operator and they conflict, raise an ambiguity error. If they are equivalent, pick one arbitrarily.
This allows operator declarations within the current module to override imported declarations if desired or to disambiguate conflicting operator declarations.
I've updated the standard library and the tests. stdlib2 and some of the examples still need to be updated.
Swift SVN r4629
Unfortunately, this regresses the repl when expressions like (1,2) are entered. This is because the repl is violating some invariants (forming dags out of ASTs, making ASDAG's which upset the type checker). I'm going to fix this next, but can't bring myself to do it in the same commit.
Swift SVN r4617
At the top level, if 'operator' is followed by 'infix', 'prefix', or 'postfix', consider it a contextual keyword, and parse an operator decl following it that looks like:
operator {infix|postfix|prefix} <+> {
attributes…
}
Prefix and postfix operator decls currently admit no attributes. Infix operators have 'associativity {left|right|none}' and 'precedence <int>' attributes.
This patch implements parsing for operator declarations but does not yet attach the declared attributes to func decls for the operators.
Swift SVN r4596
We use three tag bits on Expr*, Stmt*, Decl*, TypeBase* and SILTypeInfo*, and four on DeclContext*, so set the alignment of the pointed-to types formally with alignas(N) instead of relying on operator new passing down the right alignment to the allocator. Get rid of the informal T::Alignment members of these classes and pass alignof(T) to their allocators. Fix the 'operator new' of DeclContext subclasses so that we can actually use the four tag bits PointerLikeTypeTraits<DeclContext*> claims are available.
Swift SVN r4587
