This is an archive of the discontinued LLVM Phabricator instance.

[NFC] [clang] Forward forwarding reference
ClosedPublic

Authored by ccotter on Feb 12 2023, 9:30 PM.

Details

Summary

Update function bodies to forward forwarding references.
I spotted this while authoring a clang-tidy tool for CppCoreGuideline F.19

Diff Detail

Event Timeline

ccotter created this revision.Feb 12 2023, 9:30 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 12 2023, 9:30 PM
ccotter requested review of this revision.Feb 12 2023, 9:30 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 12 2023, 9:30 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

any chance this is testable, maybe in a unit test?

Realistically, I'm not sure if this change is all that valuable aside from abiding by the CppCoreGuidelines from the readability and consistency standpoint. The only impact this change would have that I can think of is allowing an object with an && (or other combination) qualified operator() that would be picked up by this change, which doesn't seem likely of a use case for this function. I'll try to add a small test that covers this and leave it to the maintainers whether this is a worthy change :)

ccotter updated this revision to Diff 497146.Feb 13 2023, 4:27 PM
  • Add test
dblaikie added a subscriber: iains.Feb 27 2023, 3:06 PM

Although we may not agree such ideas, we should offer an option for the users to give them the right to choose.

I think @iains was bemoaning the large number of module flags recently - perhaps he'd have some thoughts on this, but mine are that we should be more prescriptive - figure out what a good solution is for most users and implement that, rather than giving people lots of knobs to tune.

For this issue - honestly I think it might be a better/safer default to not import external module definitions at all/ever. Leave it to LTO to do that kind of cross-module optimization, as we have in the past/non-modular builds.

At least until/unless we implement something more like what the bug describes - doing IR level optimizations first and importing the optimized IR, rather than reoptimizing these external definitions in every user.

Although we may not agree such ideas, we should offer an option for the users to give them the right to choose.

I think @iains was bemoaning the large number of module flags recently - perhaps he'd have some thoughts on this, but mine are that we should be more prescriptive - figure out what a good solution is for most users and implement that, rather than giving people lots of knobs to tune.

For this issue - honestly I think it might be a better/safer default to not import external module definitions at all/ever. Leave it to LTO to do that kind of cross-module optimization, as we have in the past/non-modular builds.

At least until/unless we implement something more like what the bug describes - doing IR level optimizations first and importing the optimized IR, rather than reoptimizing these external definitions in every user.

Huh, this ended up on quite the wrong review... fascinating.

Sorry about that. Disregard. I'll follow up with on-topic review feedback here shortly.

dblaikie accepted this revision.Feb 27 2023, 4:09 PM

Looks good, thanks!

Can you commit this yourself, or would you like me to commit it on your behalf? (what name/email address would you like it attributed to?)

This revision is now accepted and ready to land.Feb 27 2023, 4:09 PM

I don't have commit access - could you use Author: Chris Cotter <ccotter14@bloomberg.net>? Thanks!

This revision was automatically updated to reflect the committed changes.