<div dir="ltr"><div dir="ltr">>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. </div><div>Maybe those functions does not have a parameter, but I am guessing now.</div><div dir="ltr"><br></div><div dir="ltr">> On the other hand, entries in ctu-dir do not contain #type.<br class="gmail-Apple-interchange-newline"></div><div>Do you mean that the CTU lib fails to find the function?</div><div><br></div><div>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.</div><div>I suggest you to use CodeChecker (<a href="https://github.com/Ericsson/codechecker/">https://github.com/Ericsson/codechecker/</a>) to orchestrate the CTU analysis, scan-build is abandoned regarding CTU.</div><div dir="ltr"><br></div><div dir="ltr">> Can this kind of conflicts happen for functions also?<br></div><div>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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 20, 2019 at 6:04 PM Kihong Heo <<a href="mailto:kihong.heo@gmail.com">kihong.heo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Thanks.<br><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">> But this is a C program. What does template mean in C?</div><div class="gmail_attr">That appears to be a simple C function then with two ulong params.</div></div></div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div> > Also, ASTImporter sometimes raises “name conflict” even though the function has a unique name and the AST file is in ctu-dir.</div><div>You may get a "name conflict" if two nodes in the merged AST has different definitions.</div><div>Here is one example with two TUs:</div><div>// a.c</div><div>enum A { x, y, z };</div><div>// b.c<br></div><div>enum B { z };</div><div>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.</div></div></div></div></blockquote><div><br></div><div>Can this kind of conflicts happen for functions also?</div><div><br></div>I appreciate your help.</div><div><br></div><div>- Kihong </div><div><br></div><div><br></div><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Gabor</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><blockquote type="cite"><div>On May 20, 2019, at 8:38 AM, Gábor Márton <<a href="mailto:martongabesz@gmail.com" target="_blank">martongabesz@gmail.com</a>> wrote:</div><br class="gmail-m_6444167911757827478gmail-m_-6520166798576337586Apple-interchange-newline"><div><div dir="ltr">Taking a look at USRGeneration.cpp, it seems to me that '#l#l' indicates two (template?) arguments with ulong types.<div><br></div><div>Gabor</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 18, 2019 at 10:43 PM Kihong Heo via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi list,<br>
<br>
index::generateUSRForDecl sometimes returns USR names followed by special characters such as<br>
<br>
c:@F@UA_memoryManager_calloc#l#l<br>
c:ua_types.c@F@clear_noInit#*v#*1$@S@UA_DataType#<br>
<br>
Could someone explain what “#l#l” mean?<br>
And the second case looks quite different from other cases. It would be appreciated if you could give some explanation.<br>
<br>
Thanks,<br>
Kihong<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>
</div></blockquote></div><br></div></div></blockquote></div></div>
</div></blockquote></div><br></div></blockquote></div></div>