<div dir="ltr"><div>Richard,</div><div><br></div><div>Thanks for the review feedback!</div><div><br></div>Here's an alternate version that better handles cases (such as the example you gave) where the code is actually valid without the "-" or ">" being changed to "->", by only trying the correction if an error diagnostic would have been emitted. It is similar to what I had mentioned doing, except that if the correction fails, ParseRHSOfBinaryExpr is called a second time to emit the original diagnostic messages. I ended up doing it this way because I encountered a problem with my previous idea: how to get the token stream in the right state if the correction fails and the original errors should be emitted. Preprocessor::EnableBacktrackAtThisPos() and friends work for resetting the token stream after the call to ParseRHSOfBinaryExpr but don't quite work for setting the token stream back to the state after the (first) call to ParseRHSOfBinaryExpr after trying the correction and having it fail (emitting the stored diagnostics from the call to ParseRHSOfBinaryExpr to avoid having to call it a second time only works if the token stream can also be restored to the correct state).<div>

<br></div><div>Cheers,</div><div>Kaelyn</div></div>