We want to enforce the invariant that invalid ValueDecls have type ErrorType.
This patch adds that check, and fixes up the last few places which violated
it.
Last part of <rdar://problem/10157547>.
Swift SVN r7960
MemberRefExpr now uses ConcreteDeclRef to refer to its member, which
includes the substitutions and obviates the need for
GenericMemberRefExpr.
Swift SVN r7842
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
This is a baby step toward eliminating GenericParamList from
PolymorphicFunctionType, fixing up the easy callers. No functionality
change.
Swift SVN r7370
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
Every valid source location corresponds to a source buffer. There should be no
cases where we create a source location for a random string. Thus,
findBufferContainingLoc() always succeeds.
Swift SVN r7120
- 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
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
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
A SuperRefExpr semantically includes an upcast, and coercing it to a deeper subclass by wrapping it in a DerivedToBaseExpr is redundant and confuses SILGen. Instead, update the type of the SuperRefExpr directly before loading from it. Fixes <rdar://problem/14581294>.
Swift SVN r6720
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
Restore ProtocolType to its proper always-canonical-typedness, now
that the type checker isn't conflating "canonical" with "no
interesting conversions".
Swift SVN r6451
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
This the first part for improving source location fidelity for types,
changes to follow:
-The Parser will not create any types, it will just create TypeReprs.
-The type checker will create the types by going through TypeReprs.
-IdentifierType will be removed.
Swift SVN r6112
The idea for now is that this is a SIL-only type used for
representing the storage of a weak or unowned reference.
Having it be its own type is pretty vital for reasonable
behavior in SIL and IR-generation, and it's likely that
this will surface into runtime metadata as well (hence
the mangling).
I've implemented a bunch of things that technically I don't
think are necessary if this stays out of the typechecker,
but it's easier to implement half-a-dozen "recurse into
the child type" methods now that it would be to find them
all later if we change our minds.
Swift SVN r6091
When we are interpreting escape sequences in the lexer, we copy the string
literal bytes to ASTContext instead of storing a pointer to the source buffer.
But then we used to try to get a source location for that string in the heap,
which is not a valid source buffer. It succeeds during parsing, but breaks
when we try to print a diagnostic using this location.
Added a verifier check for this.
Also added a real source range for StringLiteralExpr, instead of a source range
with begin == end, produced from the beginning location.
Swift SVN r5961
A single case block can have one or more 'case ...:' labels. 'case' labels contain patterns instead of exprs. 'default:' is a funny spelling for 'case _:'. Change the CaseStmt representation and rip out all the parsing, type-checking, and SILGen built off the old representation.
Swift SVN r5795
Improve our representations of casts in the AST and SIL so that 'as!' and 'is' (and eventually 'as?') can share almost all of the same type-checking, SILGen, and IRGen code.
In the AST, we now represent 'as!' and 'is' as UnconditionalCheckedCastExpr and IsaExpr, respectively, with the semantic variations of cast (downcast, super-to-archetype, archetype-to-concrete, etc.) discriminated by an enum field. This keeps the user-visible syntactic and type behavior differences of the two forms cleanly separated for AST consumers.
At the SIL level, we transpose the representation so that the different cast semantics get their own instructions and the conditional/unconditional cast behavior is indicated by an enum, making it easy for IRGen to discriminate the different code paths for the different semantics. We also add an 'IsNonnull' instruction to cover the conditional-cast-result-to-boolean conversion common to all the forms of 'is'.
The upshot of all this is that 'x is T' now works for all the new archetype and existential cast forms supported by 'as!'.
Swift SVN r5737
Change AssignStmt into AssignExpr; this will make assignment behave more consistently with assignment-like operators, and is a first step toward integrating '=' parsing with SequenceExpr resolution so that '=' can obey precedence rules. This also nicely simplifies the AST representation of c-style ForStmts; the initializer and increment need only be Expr* instead of awkward Expr*/AssignStmt* unions.
This doesn't actually change any user-visible behavior yet; AssignExpr is still only parsed at statement scope, and typeCheckAssignment is still segregrated from the constraint checker at large. (In particular, a PipeClosureExpr containing a single assign expr in its body still doesn't use the assign expr to resolve its own type.) The parsing issue will be addressed by handling '=' during SequenceExpr resolution. typeCheckAssignment can hopefully be reworked to work within the constraint checker too.
Swift SVN r5500
Technically, they are always canonical, but so are oneof/struct/class
types, and we don't classify them as "always canonical" because we
typically want to give them special semantics. Eliminates an
embarrassing bug wherein we couldn't handle conversion of
existentials.
Swift SVN r5289
Whether or how the condition of a ternary expression type-checks is a
separate problem from the then/else branches of the ternary
expression. Actually treat it as such.
This eliminates the last place in the frontend where we mode-switch
into the old type checker intentionally. It's still used in various
places externally in the test suite (via -no-constraint-checker) and
implicit (e.g., via calls to semaApplyExpr).
Swift SVN r5285
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
Start factoring out the logic that computes the mapping from one tuple
type to another. We're only using it in one place now (the
tuple-to-tuple coercion), but it should be picked up by the constraint
checker's type-matching code.
Also, fix the temporary statistics covering how much is going through
the old coercion code. With this change, we're only missing 40 of 4548
of the coercions in swift.swift (all of which appear to be string
interpolations, function type conversions, or user-defined
conversions).
Swift SVN r5087
Validating the type ensures that we collect all of the
protocol-conformance bindings we need for the bound generic
types. Additionally, check that BoundGenericTypes have exactly the
right number of arguments, which would have caught the bug fixed in
r5050.
Fixes <rdar://problem/13818785>.
Swift SVN r5062
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
One can now attach an initializer to a member variable. That value
will used as the default initialization for the member variable(s) it
initializes. Fixes <rdar://problem/12597404>.
Swift SVN r4989
