<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><div dir="ltr"><br><blockquote type="cite">On Nov 24, 2021, at 5:00 AM, benicsbalazs@gmail.com wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="Generator" content="Microsoft Word 15 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--><div class="WordSection1"><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Thanks for your response David!<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Actually, clang-tidy does something similar in the misc-redundant-expression check.<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> ...<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> areEquivalentNameSpecifier(<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> cast<DependentScopeDeclRefExpr>(Left)->getQualifier(),<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> cast<DependentScopeDeclRefExpr>(Right)->getQualifier());<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">static bool areEquivalentNameSpecifier(const NestedNameSpecifier *Left,<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> const NestedNameSpecifier *Right) {<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> llvm::FoldingSetNodeID LeftID, RightID;<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> Left->Profile(LeftID);<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> Right->Profile(RightID);<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> return LeftID == RightID;<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">}<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">But when I try to create a positive test case I fail.<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">At line 7 in the next example, I don’t get a warning.<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">It is because the folding set nodes (`LeftID` and `RightID`) are different.<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Just like the pointer values of `Left` and `Right`.<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">I'm surprised about this, since I'm referring to the very same variable, thus I would expect the same pointer values.<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">When I dump nested name specifiers I get the same string: “my_trait<char>::”<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">1 template <bool V> struct boolean_value {<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">2 static constexpr bool value = V;<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">3 };<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">4 template <typename T> struct my_trait : boolean_value<true> {};<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">5 bool respect_nested_name_specifiers(bool sink) {<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">6 sink = my_trait<char>::value || my_trait<int>::value; // no-warning, awesome<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">7 sink = my_trait<char>::value || my_trait<char>::value; // no warning for this either :(<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">8 return sink;<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">9 }<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><br>How is it possible to have different NestedNameSpecifier pointers describing the same thing?<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Am I missing something?</span></p></div></div></blockquote><blockquote type="cite"><div dir="ltr"><div class="WordSection1"><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Thanks,<o:p></o:p></span></p><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Balázs<br></span></p></div></div></blockquote><div><br></div><div>NestedNameSpecifier holds syntax info, and so has no particular obligation to unique even for identical syntax and semantics, like say a canonical type needs to be. Only by calling one of its getAs* methods can you access the underlying semantics you probably want to test.</div><div><br></div><div>You probably want to use getAsType, since that shouldn’t crash like getAsRecordDecl might and will give you flexibility eg:</div><div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">using charB = char;</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">sink = my_trait<char>::value || my_trait<charB>::value; // should this warn?</div></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">If that should warn, then you want to compare the getQualifier()->getAsType()s without desugaring; if it shouldn’t, you probably should just compare the canonical types (RecordTypes); if more complex, manually desugar step by step.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div><div>All this said, even though two NNSs representing identical syntax and semantics don’t strictly need to be the same pointer, I’m slightly surprised they aren’t - I assumed NestedNameSpecifierLocBuilder handled that sort of thing - but probably it is the case that the savings of reusing NNSs don’t exceed its costs. (Though, it seems like the same rationale would apply to sugar types, which I believe are unique/reused.)</div><div><br></div><div><br></div><div> </div><br><blockquote type="cite"><div dir="ltr"><div class="WordSection1"><p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><br><o:p></o:p></span></p><div><div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> David Rector <davrecthreads@gmail.com> <br><b>Sent:</b> 2021. november 23., kedd 23:39<br><b>To:</b> Benics Balázs <benicsbalazs@gmail.com><br><b>Cc:</b> cfe-dev <cfe-dev@lists.llvm.org><br><b>Subject:</b> Re: [cfe-dev] Same AST for is_same<char, int>::value and is_same<char, long>::value<o:p></o:p></span></p></div></div><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">Comparing the getQualifier()->getAsRecordDecl()s of the two DeclRefExprs should do it I think (untested). Careful though, NNS::getAsRecordDecl() crashes instead of returning null if the qualifier is e.g. a namespace, check its implem for the permissible kinds (or maybe better to add a getAsRecordDeclUnsafe() method).<o:p></o:p></p><div><div><p class="MsoNormal"><br><br><o:p></o:p></p><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><p class="MsoNormal" style="margin-bottom:12.0pt">On Nov 23, 2021, at 11:03 AM, Benics Balázs via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p></blockquote></div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div><p class="MsoNormal"> <o:p></o:p></p><div><p class="MsoNormal" style="background:white"><span style="color:#212121">(Resending from my personal email address)<o:p></o:p></span></p></div><div id="ms-outlook-mobile-signature"><div><p class="MsoNormal"><o:p> </o:p></p></div></div><div id="id-55f9e2ca-f8f6-43bd-a783-9b031c3c0c46"><div><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p></div><div class="MsoNormal" align="center" style="text-align:center"><hr size="2" width="98%" align="center"></div><div id="divRplyFwdMsg"><p class="MsoNormal"><strong><span style="font-family:"Calibri",sans-serif">From:</span></strong> Balázs Benics <<a href="mailto:balazs.benics@sigmatechnology.se">balazs.benics@sigmatechnology.se</a>><br><strong><span style="font-family:"Calibri",sans-serif">Sent:</span></strong> Tuesday, November 23, 2021, 14:45<br><strong><span style="font-family:"Calibri",sans-serif">To:</span></strong> cfe-dev<br><strong><span style="font-family:"Calibri",sans-serif">Subject:</span></strong> Same AST for is_same::value and is_same::value<br><br><o:p></o:p></p></div><p class="MsoNormal"><o:p> </o:p></p><div><p class="MsoNormal"><span lang="EN-US">I seek some advice on the following AST scenario.</span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US"><a href="https://godbolt.org/z/WcTeoGcbG">https://godbolt.org/z/WcTeoGcbG</a></span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US">1 #include <type_traits></span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US">2 using std::is_same;</span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US">3 bool top() {</span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US">4 return is_same<char, int>::value || is_same<char, long>::value;</span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US">5 }</span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US">The `alpha.core.IdenticalExpr` static analyzer checker warns about that the two `..::value` are identical DeclRefExprs.</span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US">According to the AST, they are indeed identical:</span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US"> BinaryOperator <col:10, col:60> 'bool' '||'</span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US"> |-ImplicitCastExpr <col:10, col:30> 'bool':'bool' <LValueToRValue></span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US"> | `-DeclRefExpr <col:10, col:30> 'const bool':'const bool' lvalue Var 0x563b67cde0a8 'value' 'const bool':'const bool'</span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US"> `-ImplicitCastExpr <col:39, col:60> 'bool':'bool' <LValueToRValue></span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US"> `-DeclRefExpr <col:39, col:60> 'const bool':'const bool' lvalue Var 0x563b67cde0a8 'value' 'const bool':'const bool'</span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US">Both of them refers to the same `VarDecl`, corresponding (probably) to the `std::false_type::value`.</span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US">How can I detect that even though the `values` look similar, they correspond to different template instances in that sense?</span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US">What do you suggest?</span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US">In the end, I want to suppress these reports in the static analyzer.</span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p><p class="MsoNormal"><span lang="EN-US">Balázs</span><o:p></o:p></p></div><p class="MsoNormal"><o:p> </o:p></p></div><p class="MsoNormal">_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><o:p></o:p></p></div></blockquote></div></div></div></blockquote></body></html>