This is an archive of the discontinued LLVM Phabricator instance.

Remove special error recovery for ::(id)
ClosedPublic

Authored by rnk on Oct 21 2016, 2:50 PM.

Details

Summary

The code pattern used to implement the token rewriting hack doesn't
interact well with token caching in the pre-processor. As a result,
clang would crash on 'int f(::(id));' while doing a tenative parse of
the contents of the outer parentheses. The original code from PR11852
still doesn't crash the compiler.

This error recovery also often does the wrong thing with member function
pointers. The test case from the original PR doesn't recover the right
way either:

void S::(*pf)() = S::f; // should be 'void (S::*pf)()'

Instead we were recovering as 'void S::*pf()', which is still wrong.

If we still think that users mistakenly parenthesize identifiers in
nested name specifiers, we should change clang to intentionally parse
that form with an error, rather than doing a token rewrite.

Fixes PR26623, but I think there will be many more bugs of this nature
due to other token rewriting attempts.

Diff Detail

Repository
rL LLVM

Event Timeline

rnk updated this revision to Diff 75490.Oct 21 2016, 2:50 PM
rnk retitled this revision from to Remove special error recovery for ::(id).
rnk updated this object.
rnk added reviewers: rsmith, rtrieu.
rnk added a subscriber: cfe-commits.
rsmith edited edge metadata.Oct 21 2016, 3:27 PM

Can you also remove the corresponding diagnostic?

lib/Parse/ParseExprCXX.cpp
73–75 ↗(On Diff #75490)

This seems to mess up the cached token buffer in the same way; it's a little surprising we don't see problems here too.

rnk added inline comments.Oct 21 2016, 4:04 PM
lib/Parse/ParseExprCXX.cpp
73–75 ↗(On Diff #75490)

Fuzzing shows that there are more ways to trigger this assertion, so whether we keep this recovery mode or not, we might want to implement that token rewrite functionality.

rnk updated this revision to Diff 75509.Oct 21 2016, 4:41 PM
rnk edited edge metadata.
  • Remove unused diagnostic
rnk added a comment.Dec 9 2016, 9:40 AM

I think the last time we discussed this, we decided that to truly fix this we need to audit all calls to PP.EnterToken(Stream) from the parser. They are probably broken in token caching mode. I haven't been able to find the time to do that. Should we commit this in the meantime, since we think this error recovery is questionable and adds unnecessary complexity?

rsmith accepted this revision.Dec 9 2016, 9:45 AM
rsmith edited edge metadata.
This revision is now accepted and ready to land.Dec 9 2016, 9:45 AM
This revision was automatically updated to reflect the committed changes.