Find a solution to annotate forwarding functions like std::make_unique

[usx95]

#include <iostream>
#include <memory>

struct A {
    std::string_view data;
    A(const std::string& a [[clang::lifetimebound]]) : data(a) {}
    std::string_view getData() { return data; }
};

std::unique_ptr<A> bar() {
    std::string on_stack = "I live on stack";
    std::unique_ptr<A> obj = std::make_unique<A>(on_stack);
    return obj; // return stack address of locak 'on_stack'
}

int main() {
    std::unique_ptr<A> obj = bar();
    std::cout << obj->getData();
}

https://godbolt.org/z/ozo5q4Wx1

[llvmbot]

@llvm/issue-subscribers-clang-temporal-safety

Author: Utkarsh Saxena (usx95)

Details

```cpp #include <iostream> #include <memory>

struct A {
std::string_view data;
A(const std::string& a [[clang::lifetimebound]]) : data(a) {}
std::string_view getData() { return data; }
};

std::unique_ptr<A> bar() {
std::string on_stack = "I live on stack";
std::unique_ptr<A> obj = std::make_unique<A>(on_stack);
return obj; // return stack address of locak 'on_stack'
}

int main() {
std::unique_ptr<A> obj = bar();
std::cout << obj->getData();
}

https://godbolt.org/z/ozo5q4Wx1
</details>

[usx95]

Consider this definition of make_unique:

template<typename T, typename... Args>
std::unique_ptr<T> make_unique(Args&&... args) {
  return std::unique_ptr<T>(new T(std::forward<Args>(args)...));
}

Atm, we do not have a good solution for forwarding functions. It is not clear when functions like these capture the argument and when they do not.
It entirely depends on the function to whom the arguments are forwarded and annotations on the forwarded function (As constructor in the main example)

[Xazax-hun]

Most of these templated forwarding functions should be available in the headers. Some random ideas, not sure if any of these are good though:

• For these functions, we could run the analysis on the specialization and use the state of the dataflow analysis to infer the lifetimebound annotations. Inject the annotations in the AST.
• "Inline" them at the call site, i.e., the fact generator can generate facts for the body of the called function inline with the assignment facts between the arguments and the parameters.
• Do proper inter-procedural analysis for these functions

[jvoung]

This is probably common to several analyses -- we also hit this in nullability. For now, we essentially inlined the make_unique case (around here) to start with, but something more general would be nice.

[usx95]

For these functions, we could run the analysis on the specialization and use the state of the dataflow analysis to infer the lifetimebound annotations. Inject the annotations in the AST.

This looks like a very promising direction to explore. Annotation inference can be used to address this in a much general way. In that case, I am not a big fan of a inlining the facts of the callee to the caller and would prefer the annotations to communicate the lifetime contracts across functions if possible.

This is probably common to several analyses -- we also hit this in nullability. For now, we essentially inlined the make_unique case (around here) to start with, but something more general would be nice.

Looks like a good approach to seed the lifetime inference in the call hierarchy. Filed #164259 separately.

Thanks both.