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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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. |
llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp | ||
---|---|---|
710 | Makes sense to me, thanks! |
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? |
llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp | ||
---|---|---|
710 | Hm, good point. We should avoid auto type deduction when the type is so obvious. |
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.
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.
Perhaps ForwardedRegWorklist even should be passed as a parameter? That could further show the intent of the function.