Commit Graph

6 Commits

Author SHA1 Message Date
Jordan Rose
91b72d3802 Fold the rest of PointerLikeTypeTraitsFwdDecl.h into TypeAlignments.h.
TypeAlignments.h predates this whole mess; it was used for types with
stronger alignment in PointerLikeTypeTraits than the old default of
"2 by fiat and assumption". All remaining forward-declared types are
AST types, so fold them into TypeAlignments.h.

(The one exception is SILTypeList.h, but that's already gone on master.)

To avoid future ODR issues, explicitly include TypeAlignments.h into
every header that defines a type it forward-declares.

I wish we could use partial specialization to provide PointerLikeTypeTraits
for all derived classes of Decl, TypeBase, etc, but that's not something
you can do in C++ if you don't control the traits class.
2016-02-06 11:22:28 -08:00
Zach Panzarino
e3a4147ac9 Update copyright date 2015-12-31 23:28:40 +00:00
Chris Lattner
e0ea37c1ed Sketch out a new representation for parameter lists in functions and closures,
to eventually replace parameter patterns.  NFC since it isn't used yet.
2015-12-27 22:19:36 -08:00
Doug Gregor
797f863d12 Don't null out the expression in an ExprHandle; it breaks invariants.
Fixes <rdar://problem/14564964>.


Swift SVN r7022
2013-08-07 23:37:43 +00:00
Doug Gregor
8c88a494b6 Make type validation slightly more robust by caching the result.
Previously, calling type validation twice for the same type could
result in spurious errors in default arguments of tuple types. Guard
against this by recording within the ExprHandle whether the default
argument has been type-checked or not, so that it will only be done
once.

Similarly, extend the type-validation caching within TypeBase to
specify the result of type validation (succeed or fail), so that
repeated calls to validateType() will produce predictable results for
failed types.


Swift SVN r5485
2013-06-06 05:39:09 +00:00
Eli Friedman
f1f67db652 Big cleanup for how we handle computing types for functions and semantic
analysis for patterns.

Major changes:
1. We no longer try to compute the types of functions in the parser.
2. The type of a function always matches the type of the argument patterns.
3. Every FuncDecl now has a corresponding FuncExpr; that FuncExpr might not
   have a body, though.
4. We now use a new class "ExprHandle" so that both a pattern and a type
   can hold a reference to the same expression.

Hopefully this will be a more reasonable foundation for further changes to
how we compute the types of FuncDecls in generics and for the implementation
of type location information.



Swift SVN r2370
2012-07-19 02:09:04 +00:00