This is an archive of the discontinued LLVM Phabricator instance.

[demangler][NFC] OperatorInfo table unit test
ClosedPublic

Authored by urnathan on Apr 8 2022, 7:02 AM.

Details

Summary

Placing a run-once test inside the operator lookup function caused problems with the thread sanitizer. See D122975.

D123158 attempted to address the warning with an atomic once-only approach, but missed the libcxxabi use.

This break out the operator table into a member variable, and move the test to the unit test machinery.

I have verify the unit test triggers, if you do misorder the table.

(The table could be shared across instantiations of the demangler, but that requires either inline-vars (a c++17 thing), or a separate object file.)

Diff Detail

Event Timeline

urnathan created this revision.Apr 8 2022, 7:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 8 2022, 7:02 AM
urnathan requested review of this revision.Apr 8 2022, 7:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 8 2022, 7:02 AM

Thanks for following up on this Nathan! No concerns from me, but I probably shouldn't be the one accepting this patch.

llunak removed a reviewer: llunak.Apr 10 2022, 4:58 AM
llunak added a subscriber: llunak.

Would a more direct fix be, rather than using the C++ library call_once feature, instead using the equivalent language feature:

static int unused = [&]() {
  /* whatever you want to do once */
}, 0;

Though if we can move the logic out of the production codepath and into a test entirely, that does seem better anyway - so this is probably the right direction. (I probably won't be the one to approve this - maybe @JDevlieghere has a bit more context in this chain of patches)

um, it seems that although both @JDevlieghere and @dblaikie like the direction of this patch, neither wishes to commit. pretty please?

Oh, sorry I missed that Jonas had also passed on this. I'll give it another look (might be later this week though) with an eye for approval

To clarify: I think this change looks perfectly fine. The only reason I didn't want to accept this is because I'm not at all familiar with libc++. Case in point: I accepted D123158 which turned out not to be the right thing :-)

The change looks good to me too, if that counts as anything from an outsider. But as an outsider I think you LLVM folks tend to overdo the perfectionism while reviewing. There's rather obviously nothing visibly wrong with the change, the chance it'll break something is extremely low, you apparently know this code, and you pushing this should be fine even according to the policy (the "likely-community-consensus" part) rather than blocking on somebody who apparently has a long enough review queue and could be instead reviewing changes that actually need it (*cough* D122974 *cough*).

To clarify: I think this change looks perfectly fine. The only reason I didn't want to accept this is because I'm not at all familiar with libc++. Case in point: I accepted D123158 which turned out not to be the right thing :-)

Case in point: D123158 would not have actually broken anything, so it's not a wrong thing either :).

The change looks good to me too, if that counts as anything from an outsider. But as an outsider I think you LLVM folks tend to overdo the perfectionism while reviewing. There's rather obviously nothing visibly wrong with the change, the chance it'll break something is extremely low, you apparently know this code, and you pushing this should be fine even according to the policy (the "likely-community-consensus" part)

+1 from me on all counts (as another person not familiar with the details of current libc++).

To clarify: I think this change looks perfectly fine. The only reason I didn't want to accept this is because I'm not at all familiar with libc++. Case in point: I accepted D123158 which turned out not to be the right thing :-)

I understand and agree with your reasoning, I intended no blame and am sorry if it came across that way.

To clarify: I think this change looks perfectly fine. The only reason I didn't want to accept this is because I'm not at all familiar with libc++. Case in point: I accepted D123158 which turned out not to be the right thing :-)

I understand and agree with your reasoning, I intended no blame and am sorry if it came across that way.

Not at all!

dblaikie accepted this revision.Apr 15 2022, 1:20 PM

Thanks!

This revision is now accepted and ready to land.Apr 15 2022, 1:20 PM
This revision was landed with ongoing or failed builds.Apr 25 2022, 10:02 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptApr 25 2022, 10:02 AM
Herald added 1 blocking reviewer(s): Restricted Project. · View Herald Transcript