[cfe-dev] [RFC] Upstreaming Lifetime Function Annotations

[Dmitri Gribenko via cfe-dev]

Hi Gábor,

I'm very excited about lifetime annotations! I have two comments/requests.

The first one is about the implementation. There are quite a few warnings,
ClangTidy checkers and other analyses in Clang that are dataflow-based or
at least sort of dataflow-based. They all have to implement the
interpretation of Clang's AST semantics, which is unfortunate, because it
is very complicated logic that is refined and polished over time as we get
to use those warnings and checkers, and yet, we can't reuse this logic for
any new checker.

Therefore, my request is to try to structure the implementation in such a
way that it is at least plausible to factor out the "dataflow engine" parts
of the static analysis in future, and keep the abstract domain and lifetime
specifics more or less separate.

On Thu, Dec 5, 2019 at 12:02 AM Gábor Horváth via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

>
>   const char *find(const string &haystack, const string &needle)
>       [[gsl::post(lifetime(find, {haystack, null}))]];
>

I have a concern about the bulkiness of the syntax. I understand why it
ended up this way (use standard attribute syntax, use the contracts syntax,
ensure that names are referenced syntactically after they are declared, and
we get the proposed syntax) -- that helps with rationalization, but that
does not help me justify it.

  struct Match { const char *pos; /* ... */ };
>   bool find(const string &hs, const string &n, Match *m)
>     [[gsl::post(lifetime(deref(M).pos, {haystack}))]];
>

I understand why the lifetime specification has to go at the end of the
declaration in the general case -- to handle cases like this, where we want
to specify a lifetime for some part of the data structure, but I'm not
convinced that users should always use the most general syntax. I feel like
it is going to be an adoption barrier and a readability issue.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20191212/eae3ee1f/attachment.html>