[cfe-dev] Question about lifetime bound annotation

[Vitali Lovich via cfe-dev]

I was thinking about it some more, & as long as the name of the warning
generated is unique, I don't think the false positives are a problem. The
end users can opt-in/opt-out of it being an error or a warning at all based
upon their experience in their own code base.

On Mon, May 24, 2021 at 3:39 PM Vitali Lovich <vlovich at gmail.com> wrote:

>
>
> On Mon, May 24, 2021 at 3:21 PM Richard Smith <richard at metafoo.co.uk>
> wrote:
>
>> On Mon, 24 May 2021 at 12:25, Vitali Lovich via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> I was trying to incorporate the lifetime bound in an OSS project (
>>> https://github.com/capnproto/capnproto/pull/1246) and it surfaced a
>>> potential limitation of the annotation (or perhaps I'm just not utilizing
>>> its full power yet).
>>>
>>> Is there a way to use the lifetime annotation to have the compiler track
>>> the lifetime through copies? For example, if std::string's conversion
>>> operator to std::string_view is annotated, will
>>> copying/moving/assigning the returned std::string_view (e.g. when building
>>> up a vector of string_view in a loop but accidentally having that
>>> string_view point to a string local to the loop) cause the compiler to
>>> still see the copies as having their lifetimes tied to the original
>>> std::string? One would think that defaulted copies/moves/assignments would
>>> automatically preserve the lifetime & there would need to be some kind of
>>> additional annotation for the more complex use-cases, but from my testing
>>> this is perhaps not yet implemented?.
>>>
>>
>> Yes, this should work as you describe, but that is not implemented yet.
>>
>>
>>> Relatedly, it seems even as something as simple as below didn't trigger
>>> the warning so I'm wondering if I'm misusing it or if the lifetime tracking
>>> is just very limited in the cases it can find.
>>>
>>> struct Foo {
>>>   std::string buf;
>>>   operator std::string_view() const [[clang::lifetimebound]] {
>>>     return buf;
>>>   }
>>> };
>>>
>>> int main() {
>>>   for (int i = 0; i < 5; i++) {
>>>     std::string_view x;
>>>     {
>>>       Foo str = { .buf = std::to_string(i) };
>>>       x = str;
>>>     }
>>>     std::cerr << x << "\n";
>>>   }
>>> }
>>>
>>> clang++ -std=c++20 -Wall doesn't seem to generate a warning (v13 from
>>> revision 0e92cbd6a652c). Adding -fsanitize=address does cause the
>>> program to crash when run.
>>>
>>
>> At the moment, the lifetimebound warning only considers initializations,
>> not assignments. We could in principle warn that `x = str;` assigns a value
>> with shorter lifetime to a variable with longer lifetime, though that would
>> have false positives on cases like:
>>
>> string_view x;
>> {
>>   Foo str = ...
>>   x = str;
>>   ...
>>   x = "something else";
>> }
>>
>> ... or if x is not used after the lifetime of str ends. Correctly
>> handling those cases would require a more sophisticated kind of analysis
>> than the syntactic check we currently perform. (Though perhaps the
>> simplistic analysis that warns directly on the `x = str;` assignment
>> without considering the context would be useful enough in practice, despite
>> the potential for false positives?)
>>
> ah ok. That explains it. The specific case I was hoping would be caught
> was initializing a vector of string views and accidentally using a
> reference to a string that didn’t outlive the loop itself. I was doing
> something like v[i] = std::to_string(…). I suspect the false positive would
> be fine for my specific project (although I’d need to double-check with a
> version of clang that could do that) but I can’t make the call for all
> users of clang/this annotation. I found it interesting that libc++ has not
> itself adopted this annotation and I suspect I may be one of very few
> people who’s not a clang maintaner/developer to have noticed the existence
> of the annotation in the first place and tried to use it :).
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210525/23f1baad/attachment.html>