[cfe-dev] USR for CTU analysis

[Gábor Márton via cfe-dev]

>Most of the time, generateUSRForDecl returns just function names without
#type but only a few cases have #type that block CTU analysis from loading
the corresponding ASTs.
Maybe those functions does not have a parameter, but I am guessing now.

> On the other hand, entries in ctu-dir do not contain #type.
Do you mean that the CTU lib fails to find the function?

Based on the above I suppose there may be something wrong about how you
execute the first phase (the generation of the PCH files) of the analysis.
I suggest you to use CodeChecker (https://github.com/Ericsson/codechecker/)
to orchestrate the CTU analysis, scan-build is abandoned regarding CTU.

> Can this kind of conflicts happen for functions also?
In case of extern visible functions, if you try to CTU analyze only those
TUs which normally linked together then it may not. For functions with
static visibility, they may have different signatures (and definitions) in
the different TUs, so you may have a warning/error then again.

On Mon, May 20, 2019 at 6:04 PM Kihong Heo <kihong.heo at gmail.com> wrote:

> Thanks.
>
> > But this is a C program. What does template mean in C?
> That appears to be a simple C function then with two ulong params.
>
>
> But, I don’t always see #types. Most of the time, generateUSRForDecl
> returns just function names without #type but only a few cases have #type
> that block CTU analysis from loading the corresponding ASTs. On the other
> hand, entries in ctu-dir do not contain #type.
>
>  > Also, ASTImporter sometimes raises “name conflict” even though the
> function has a unique name and the AST file is in ctu-dir.
> You may get a "name conflict" if two nodes in the merged AST has different
> definitions.
> Here is one example with two TUs:
> // a.c
> enum A { x, y, z };
> // b.c
> enum B { z };
> Now merging them would result a conflicting definition for the global enum
> constant `z` which has the value 2 in a.c and 0 in b.c. This is a
> warning/error because we cannot answer which value we should use during the
> analysis.
>
>
> Can this kind of conflicts happen for functions also?
>
> I appreciate your help.
>
> - Kihong
>
>
>
> Gabor
>
> On May 20, 2019, at 8:38 AM, Gábor Márton <martongabesz at gmail.com> wrote:
>>
>> Taking a look at USRGeneration.cpp, it seems to me that '#l#l' indicates
>> two (template?) arguments with ulong types.
>>
>> Gabor
>>
>> On Sat, May 18, 2019 at 10:43 PM Kihong Heo via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> Hi list,
>>>
>>> index::generateUSRForDecl sometimes returns USR names followed by
>>> special characters such as
>>>
>>> c:@F at UA_memoryManager_calloc#l#l
>>> c:ua_types.c at F@clear_noInit#*v#*1$@S at UA_DataType#
>>>
>>> Could someone explain what “#l#l” mean?
>>> And the second case looks quite different from other cases. It would be
>>> appreciated if you could give some explanation.
>>>
>>> Thanks,
>>> Kihong
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190520/5de6eb66/attachment.html>