<div dir="ltr">Barring any replies with concerns, ideas for improving the patch, or suggestions for a differrent approach, I'll probably commit it on Monday.<div><br></div><div>Cheers,</div><div>Kaelyn</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Nov 1, 2013 at 9:42 AM, Kaelyn Uhrain <span dir="ltr"><<a href="mailto:rikka@google.com" target="_blank">rikka@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Serge,<div><br></div><div>The trouble I was having wasn't so much about giving Sema enough context to make the correction, but about being able to hit the right code paths at the right times to be able to 1) have some confidence that the correction is even semi-reasonable, and 2) to be able to suppress duplicate/extraneous errors and ideally recover from the typo.</div>
<div><br></div><div>For "foo->bar", the parser handles "foo" as the LHS by calling Parser::ParseCastExpression that eventionally calls down into Sema and comes back, then ParseCastExpression sees the arrow and calls ParsePostfixExpressionSuffix which handles the member lookup of "bar" with Sema's help as the final part of building the LHS. Then the parser goes back out to Parser::ParseAssignmentExpression (which called ParseCastExpression to create the LHS expression) and calls Parser::ParseRHSOfBinaryExpression for the pieces of the expression that come after "foo->bar".</div>
<div><br></div><div>If "foo->bar" is mistyped as "foo-bar" or "foo>bar", the parser handles "foo" as above, but returns back to ParseAssignmentExpression and calls ParseRHSOfBinaryExpression to handle "-bar"/">bar". Then it isn't until after the "-" or ">" has been parsed and the parser is calling into Sema to figure out what "bar" is that an error is encountered. To recover from the error at the point Sema encounters it, Sema would have to be able to tell the parser to undo the parsing of RHS of a binary expression and the operator that triggered it, redo the parsing of the LHS enough to call ParsePostfixExpressionSuffix for the post-recovery "->bar", and go on to re-invoke ParseRHSOfBinaryExpression on whatever comes after "bar". Or, as in my patch, the parser can preemptively check for the conditions under which the error may occur (with the assumption that minus and greater-than are operations rarely performed on pointers to record objects in valid code and so the overhead in such a situation is acceptable) to see whether "bar" by itself refers to anything, and if the lookup fails and treating bar as a member works, assume the "-" or ">" was intended to be "->".</div>
<div><br></div><div>Cheers,</div><div>Kaelyn</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 1, 2013 at 12:55 AM, Serge Pavlov <span dir="ltr"><<a href="mailto:sepavloff@gmail.com" target="_blank">sepavloff@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Another approach is to inform Sema about context where the unknown name occurs. That would allow typo correction code to be gathered in one place in Sema. Such kind of typos could be processed by the same machinery in ActOnIdExpression, which now tries to make correction of misspelled names.<div>
<br><div>There are other typos that are nice to handle ("." vs ".*", dot instead of comma etc). Handling them in Parser could make the latter bulky.</div><div><br></div><div>Thanks,</div><div>--Serge</div>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/1 Kaelyn Uhrain <span dir="ltr"><<a href="mailto:rikka@google.com" target="_blank">rikka@google.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>
<div dir="ltr">Attached is an initial patch for trying to correct a missing "-" or ">" to "->" when accessing a member through an object pointer. This patch also doesn't work for C code as C seems to hit a different code path. I'm sending the patch out for pre-commit review even though it is a small and fairly unobtrusive (code-wise) patch because I'm a bit iffy on whether it's a good way to perform the diagnostic.<div>
<br></div><div>For a bit of context, what makes this diagnostic tricky is that the original error about the unknown identifier after the "-" or ">" occurs well within Sema as the parser is handling the RHS of a binary operator, but the recovery would require following a code path in the parser that was part of the construction of the LHS. And since Sema cannot tell the parser to back up a few steps....</div>
<div><br></div><div>Cheers,</div><div>Kaelyn</div></div>
<br></div></div>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br>Thanks,<br>--Serge<br>
</font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>