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

[David Blaikie via llvm-commits]

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/7c40e720/attachment-0001.html>