Doug Gregor e7f5f3da01 Set the type of class/struct/union declarations during type checking. ...

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

2013-08-22 00:57:38 +00:00

75 KiB

Raw Blame History

View Raw