Skip to content

C++: Support x-macros that are #undef'ed in header #1836

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Aug 28, 2019

Conversation

jbj
Copy link
Contributor

@jbj jbj commented Aug 28, 2019

This change should address the FP reported at https://discuss.lgtm.com/t/false-positive-in-c-header/2265.

The changed predicates take negligible time on all snapshots I've tried. @geoffw0, you must have had some problematic snapshots when you wrote #313. Can you test on those?

I'll create a change note file for 1.23 in a separate PR.

@jbj jbj added the C++ label Aug 28, 2019
@jbj jbj requested a review from geoffw0 August 28, 2019 11:15
@jbj jbj requested a review from a team as a code owner August 28, 2019 11:15
@geoffw0
Copy link
Contributor

geoffw0 commented Aug 28, 2019

Changes LGTM but yes, I need to find some problematic snapshots and make sure performance is still OK...

Copy link
Contributor

@geoffw0 geoffw0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried the original (pre-#313) version of the query on 16 projects, the only ones that took over 60 seconds were:

Chromium - original 594s (218 results), master 556s (218 results), PR 558s (215 results)
Libreoffice - original 201s (219 results), master 189s (219 results), PR 188s (215 results)
Linux (full) - original 283s (676 results), master 282s (676 results), PR 280s (674 results)
UnrealEngine - original exec failed; master exec failed; PR exec failed
(timeout was only set to 600s)

It looks like I've failed to find a problematic snapshot that the first PR solves (it's also possible the modern optimizer copes with all versions of the query equally now). Nevertheless, performance is no worse in my testing, and I think the original issue was caused by exposing the macroName variable in the query itself, which your version does not do. So we should be good.

FWIW, I also investigated some of the lost results and they matched your intended pattern. 👍

@geoffw0 geoffw0 merged commit 2e0c1af into github:master Aug 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants