| 1 | From the refrat (5.5) we have our specification:
|
|---|
| 2 |
|
|---|
| 3 | \section{Initialization} An expression that is used as an
|
|---|
| 4 | \nonterm{initializer} is treated as being cast to the type of the
|
|---|
| 5 | object being initialized. An expression used in an
|
|---|
| 6 | \nonterm{initializer-list} is treated as being cast to the type of
|
|---|
| 7 | the aggregate member that it initializes. In either case the cast
|
|---|
| 8 | must have a single unambiguous
|
|---|
| 9 | interpretation\index{interpretations}.
|
|---|
| 10 |
|
|---|
| 11 | Steps:
|
|---|
| 12 |
|
|---|
| 13 | - add a member function "void Resolver::visit( SynTree::DeclStmt
|
|---|
| 14 | *declStmt )"; for each DeclStmt:
|
|---|
| 15 |
|
|---|
| 16 | - do what you need to do to establish correspondences between
|
|---|
| 17 | expressions in the initializer and pieces of the object to be
|
|---|
| 18 | initialized
|
|---|
| 19 |
|
|---|
| 20 | - for each initializer expression, construct a cast expression that
|
|---|
| 21 | casts the value of the expression to the type of the corresponding
|
|---|
| 22 | sub-object
|
|---|
| 23 |
|
|---|
| 24 | - invoke the resolver recursively on each cast expression; it's an invariant
|
|---|
| 25 | of the resolver that attempting to resolve a cast expression results either
|
|---|
| 26 | in a single resolved expression (corresponding to the unambiguous interpretation
|
|---|
| 27 | referred to above) or a thrown SemanticError.
|
|---|
| 28 |
|
|---|
| 29 | - construct a new initializer from the resolved expressions
|
|---|
| 30 |
|
|---|
| 31 | You'll undoubtedly have to play with the CodeGen stuff a bit; I
|
|---|
| 32 | hacked it to spit out unresolved initializers for file-scope
|
|---|
| 33 | declarations so that real programs would compile. You'll want to make
|
|---|
| 34 | sure that resolved initializers for all declarations are being
|
|---|
| 35 | generated.
|
|---|
| 36 |
|
|---|
| 37 |
|
|---|
| 38 | ------
|
|---|
| 39 |
|
|---|
| 40 | More recent email: (I am quoted; Richard is the responder)
|
|---|
| 41 | > As far as I'm aware, the only way that I could currently get the correct
|
|---|
| 42 | > results from the unification engine is by feeding it an expression that
|
|---|
| 43 | > looks like "?=?( ((struct Y)x.y).a, 10 )", then picking out the pieces that
|
|---|
| 44 | > I need (namely the correct choice for a). Does this seem like a reasonable
|
|---|
| 45 | > approach to solve this problem?
|
|---|
| 46 |
|
|---|
| 47 | No, unfortunately. Initialization isn't being rewritten as assignment,
|
|---|
| 48 | so you shouldn't allow the particular selection of assignment
|
|---|
| 49 | operators that happen to be in scope (and which may include
|
|---|
| 50 | user-defined operators) to guide the type resolution.
|
|---|
| 51 |
|
|---|
| 52 | I don't think there is any way to rewrite an initializer as a single
|
|---|
| 53 | expression and have the resolver just do the right thing. I see the
|
|---|
| 54 | algorithm as:
|
|---|
| 55 |
|
|---|
| 56 | For each alternative interpretation of the designator:
|
|---|
| 57 | Construct an expression that casts the initializer to the type of
|
|---|
| 58 | the designator
|
|---|
| 59 | Construct an AlternativeFinder and use it to find the lowest cost
|
|---|
| 60 | interpretation of the expression
|
|---|
| 61 | Add this interpretation to a list of possibilities
|
|---|
| 62 | Go through the list of possibilities and pick the lowest cost
|
|---|
| 63 |
|
|---|
| 64 | As with many things in the resolver, it's conceptually simple but the
|
|---|
| 65 | implementation may be a bit of a pain. It fits in with functions like
|
|---|
| 66 | findSingleExpression, findIntegralExpression in Resolver.cc, although
|
|---|
| 67 | it will be significantly more complicated than any of the existing
|
|---|
| 68 | ones.
|
|---|
| 69 |
|
|---|
| 70 |
|
|---|
| 71 |
|
|---|
