[llvm] r301152 - [Orc] Fix a warning by removing an unused lambda capture.

[Lang Hames via llvm-commits]

>
> Well, since the lambda is a unnameable type you can only really pass it to
> templates, conveniently ;)


Good point. I bet you could go a long way with an escape test that's just
checks whether the lambda was stored at all (I suspect that where it's
passed as an argument it's usually just referred to directly in the callee).

But yeah, interprocedural would be necessary to make it very effective


Definitely. Sounds like that analysis could be quite simple though. Sounds
like something fun to add to my impractically long to-do list.

- Lang.


On Sun, May 7, 2017 at 11:38 AM, David Blaikie <dblaikie at gmail.com> wrote:

> Well, since the lambda is a unnameable type you can only really pass it to
> templates, conveniently ;)
>
> But yeah, interprocedural would be necessary to make it very effective
>
>
> On Sun, May 7, 2017, 11:29 AM Lang Hames <lhames at gmail.com> wrote:
>
>> I was thinking interprocedural analysis: it works for all the STL
>> functions (and handleErrors) because those are templates so you have the
>> definitions. You're right though, in general you'd probably hit calls you
>> don't have the definition for pretty quickly.
>>
>> - Lang.
>>
>>
>> On Sun, May 7, 2017 at 10:50 AM, David Blaikie <dblaikie at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Sat, May 6, 2017 at 10:52 AM Lang Hames <lhames at gmail.com> wrote:
>>>
>>>> I think of such lambdas as basically programmatic control flow (like an
>>>>> if, while, etc) - so there's no need to explicitly state which variables
>>>>> you'll use within this nested scope.
>>>>
>>>>
>>>> Good idea.
>>>>
>>>> This is probably too heavyweight to do as a warning, but some sort of
>>>> style-checker plugin could suggest using default capture for non-escaping
>>>> lambdas and explicit capture for may-escape ones.
>>>>
>>>
>>> Yeah, pretty tricky to do, though - for example this use case would
>>> probably fall into the "may escape" case (since it's passed to another
>>> function which might then capture it into a std::function for later use,
>>> etc). Essentially only local lambdas called directly (not used by passing
>>> to any algorithm-like functions, etc) would be "doesn't escape". (or you
>>> could conservatively assume that anywhere you don't see the lambda copied
>>> to a std::function ctor is fine? Though that might aggressively encourage
>>> default capture where it shouldn't be, etc)
>>>
>>> Tricky one, I suspect,
>>> - Dave
>>>
>>>
>>>>
>>>> - Lang.
>>>>
>>>> On Mon, Apr 24, 2017 at 9:13 AM, David Blaikie <dblaikie at gmail.com>
>>>> wrote:
>>>>
>>>>> Generally if a lambda's only going to be used within its own scope -
>>>>> I'd suggest using [&]. I think of such lambdas as basically programmatic
>>>>> control flow (like an if, while, etc) - so there's no need to explicitly
>>>>> state which variables you'll use within this nested scope.
>>>>>
>>>>> On Sun, Apr 23, 2017 at 6:34 PM Lang Hames via llvm-commits <
>>>>> llvm-commits at lists.llvm.org> wrote:
>>>>>
>>>>>> Author: lhames
>>>>>> Date: Sun Apr 23 20:21:23 2017
>>>>>> New Revision: 301152
>>>>>>
>>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=301152&view=rev
>>>>>> Log:
>>>>>> [Orc] Fix a warning by removing an unused lambda capture.
>>>>>>
>>>>>> Modified:
>>>>>>     llvm/trunk/include/llvm/ExecutionEngine/Orc/RPCSerialization.h
>>>>>>
>>>>>> Modified: llvm/trunk/include/llvm/ExecutionEngine/Orc/
>>>>>> RPCSerialization.h
>>>>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/
>>>>>> llvm/ExecutionEngine/Orc/RPCSerialization.h?rev=301152&
>>>>>> r1=301151&r2=301152&view=diff
>>>>>> ============================================================
>>>>>> ==================
>>>>>> --- llvm/trunk/include/llvm/ExecutionEngine/Orc/RPCSerialization.h
>>>>>> (original)
>>>>>> +++ llvm/trunk/include/llvm/ExecutionEngine/Orc/RPCSerialization.h
>>>>>> Sun Apr 23 20:21:23 2017
>>>>>> @@ -378,7 +378,7 @@ public:
>>>>>>        return serializeSeq(C, std::string());
>>>>>>
>>>>>>      return handleErrors(std::move(Err),
>>>>>> -                        [&C, &Lock](const ErrorInfoBase &EIB) {
>>>>>> +                        [&C](const ErrorInfoBase &EIB) {
>>>>>>                            auto SI = Serializers.find(EIB.
>>>>>> dynamicClassID());
>>>>>>                            if (SI == Serializers.end())
>>>>>>                              return serializeAsStringError(C, EIB);
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> llvm-commits mailing list
>>>>>> llvm-commits at lists.llvm.org
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>>>>
>>>>>
>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170507/3273a71f/attachment.html>