[clang] False diagnositc for container for pointer with lifetimebound

[usx95]

#include <optional>
#include <string>
#include <string_view>

template <class T>
struct S {
    T foo(T&& t [[clang::lifetimebound]]);
};

void use() {
    S<std::string_view> s;
    std::string_view x = s.foo(std::optional<std::string_view>{}.value()); // False warning here.
}

cc: @hokein @Xazax-hun

[usx95]

May be the core issue is when a view type appears as a reference type param.:
https://godbolt.org/z/f1MhdqbrW

#include <optional>
#include <string>
#include <string_view>

std::string_view foo(std::string_view&& t [[clang::lifetimebound]]);
std::string_view bar(std::string_view t [[clang::lifetimebound]]);

void use() {
    std::string_view x = foo(std::string_view()); // We only warn here.
    std::string_view y = bar(std::string_view());
}

[hokein]

I think clang’s behavior is expected. Here's a simplified version of the code:

std::string_view foo(const std::string_view& abc [[clang::lifetimebound]]);

void s() {
   std::string_view abc = foo(std::string_view()); // warning: dangling
}

The lifetimebound attribute is not aware of gsl::pointer types, and std::string_view is treated like any other simple class. The attribute indicates that the return value of the function may refer to the function's parameter object. Since the parameter is a reference, its referenced object is considered -- in this case, it is the temporary std::string_view() object.
The diagnostic message expresses it (temporary whose address is used as value of local variable 'abc' will be destroyed at the end of the full-expression)

The return type of the function doesn’t affect the diagnostic. You could change the return type to something else, like int or double, and clang would still emit the diagnostic.

[Xazax-hun]

Lifetimebound always applies to the top level, in the original example to the reference. I'd say the original code is incorrectly annotated. If we want to annotate code like this we either need to introduce a new annotation, or add an argument to lifetimebound to indicate that it applies something other than the top level. I'd not go in the direction where lifetimebound applies to something other than the top level based on some heuristics. I'd be a bit concerned that this would make the behavior of the annotation harder to predict.