This is an archive of the discontinued LLVM Phabricator instance.

[clang-format][NFC] Fix a bug in getPreviousToken() in the parser
ClosedPublic

Authored by owenpan on Dec 27 2021, 12:01 PM.

Diff Detail

Event Timeline

owenpan requested review of this revision.Dec 27 2021, 12:01 PM
owenpan created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptDec 27 2021, 12:01 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
curdeius requested changes to this revision.Dec 28 2021, 4:13 AM

Wasn't assert enough? Could you add a test with code that provokes the problem?

This revision now requires changes to proceed.Dec 28 2021, 4:13 AM

Wasn't assert enough? Could you add a test with code that provokes the problem?

This fix is an NFC, so there will be no (user) test case for it. :)

The current behavior does not match the description on line 35, and I need this function to be able to return null to simply my code. Otherwise, l would have to do something like the following:

if (Position == 0)
  return false;
const FormatToken *Previous = AllTokens[Position - 1];
assert(Previous);
return Previous->is(tok::comment);

I'm against that patch.

Don't pay for what you don't use.

We should not put the size check into every call.

owenpan added a comment.EditedDec 28 2021, 1:44 PM

I'm against that patch.

Don't pay for what you don't use.

We should not put the size check into every call.

That's what you must do now without this patch, which will fix the problem. I should be able to just call getPreviousToken() without having to first check Position > 0.

Edit:
I see what you mean now. The question is if getPreviousToken() can be called when the current token is the very first token. I think it can, so you either pay now or later for what you may use.

I'm in the same position as @HazardyKnusperkeks.
If you need something to simplify the code you can add a helper getPreviousTokenOrNull or something like that in your patch.
But we certainly don't want to pay for the if check each time we call getPreviousToken.

On another note, you can fix the comment typo without a review.

I'm in the same position as @HazardyKnusperkeks.
If you need something to simplify the code you can add a helper getPreviousTokenOrNull or something like that in your patch.
But we certainly don't want to pay for the if check each time we call getPreviousToken.

I think we are going overboard here. Based on the comments, the intent was to return null for the previous token of the first token. I was the first and only one who needed to call it, and if the caller must check if it's the first token every time anyway, why not just do it in the callee and make the function more robust. Perhaps we can rename the current one to something like getPreviousTokenFast?

MyDeveloperDay accepted this revision.Jan 7 2022, 12:32 AM

I agree performance of this if is unlikely to be a game changer performance wise

This revision was not accepted when it landed; it landed in state Needs Revision.Jan 7 2022, 9:20 PM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.