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

[Gábor Horváth via cfe-dev]

Hi Dmitri,

On Thu, Dec 12, 2019 at 5:44 AM Dmitri Gribenko <gribozavr at gmail.com> wrote:

> 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.
>

Thanks, I totally agree. I think it should be relatively easy to separate
the CFG traversal/fixed point iteration part. Anything bigger is likely to
be more involved, but we definitely will strive for some reusability.


>
> 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.
>

I would love to see a simpler syntax. I think implementing this the most
general way possible and adding some syntactic sugar later on after having
some data about the most common patterns might make sense. Is it
problematic to evolve the syntax upstream? I know this would be bad for
early adopters but we could make it clear what they are opting into.

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