This is an archive of the discontinued LLVM Phabricator instance.

[NFC][DwarfDebug] Avoid default capturing when using lambdas
ClosedPublic

Authored by djtodoro on May 8 2020, 12:23 AM.

Details

Summary

It is bad practice to capture by default (via [&] in this case) when using lambdas, so we should avoid that as much as possible.
This patch fixes that in the getForwardingRegsDefinedByMI from DwarfDebug module.

Diff Detail

Event Timeline

djtodoro created this revision.May 8 2020, 12:23 AM
dstenb added inline comments.May 8 2020, 12:46 AM
llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
710

Perhaps ForwardedRegWorklist even should be passed as a parameter? That could further show the intent of the function.

djtodoro marked an inline comment as done.May 8 2020, 1:29 AM
djtodoro added inline comments.
llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
710

Makes sense to me, thanks!

djtodoro updated this revision to Diff 262834.May 8 2020, 1:30 AM

-addressing comments

dstenb accepted this revision.May 8 2020, 2:14 AM
dstenb added inline comments.
llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
710

Oh, and as TRI is a pointer maybe the reference should not be used here? Perhaps we should change the auto references to pointers at line 655-657 to stress that?

This revision is now accepted and ready to land.May 8 2020, 2:14 AM
djtodoro marked an inline comment as done.May 8 2020, 3:10 AM
djtodoro added inline comments.
llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
710

Hm, good point. We should avoid auto type deduction when the type is so obvious.
I'll add another small NFC patch refactoring that as well.

vsk accepted this revision.May 8 2020, 10:54 AM
This revision was automatically updated to reflect the committed changes.

It is bad practice to capture by default (via [&] in this case) when using lambdas

I'd say quite the opposite - default reference capture should be used by default for any lambda that does not escape its context - same as any other code block. (I think this is more unambiguous when the lambda is never named, and just immediately passed into another function like `llvm::any_of```, and I'm not 100% on never enumerating captures when a lambda is named and maybe called several times in more surprising/distant places - but this lambda is called directly, and exactly once, which makes me question the use of a lambda here - I'd consider pulling it out as a separate named function, or just removing the lambda entirely & adding a comment block describing the purpose of the code inline)

Please revert this.

I'd consider pulling it out as a separate named function, or just removing the lambda entirely & adding a comment block describing the purpose of the code inline)

Thanks for the comment and explanation! A separate function makes sense to me.

I just reverted this.

I'd consider pulling it out as a separate named function, or just removing the lambda entirely & adding a comment block describing the purpose of the code inline)

Thanks for the comment and explanation! A separate function makes sense to me.

I just reverted this.

Thanks! Yeah, if you want to pull this out into a separate top level function I'd be fine with that - given it's only capturing one value, moving that to be a normal parameter doesn't seem like it'd make this significantly less legible, etc.