[cfe-dev] Same AST for is_same<char, int>::value and is_same<char, long>::value

[via cfe-dev]

Thanks for your response David!

Actually, clang-tidy does something similar in the misc-redundant-expression check.

 

  ...

  areEquivalentNameSpecifier(

    cast<DependentScopeDeclRefExpr>(Left)->getQualifier(),

    cast<DependentScopeDeclRefExpr>(Right)->getQualifier());

 

static bool areEquivalentNameSpecifier(const NestedNameSpecifier *Left,

                                       const NestedNameSpecifier *Right) {

  llvm::FoldingSetNodeID LeftID, RightID;

  Left->Profile(LeftID);

  Right->Profile(RightID);

  return LeftID == RightID;

}

 

But when I try to create a positive test case I fail.

At line 7 in the next example, I don’t get a warning.

It is because the folding set nodes (`LeftID` and `RightID`) are different.

Just like the pointer values of `Left` and `Right`.

I'm surprised about this, since I'm referring to the very same variable, thus I would expect the same pointer values.

When I dump nested name specifiers I get the same string: “my_trait<char>::”

 

1  template <bool V> struct boolean_value {

2    static constexpr bool value = V;

3  };

4  template <typename T> struct my_trait : boolean_value<true> {};

5  bool respect_nested_name_specifiers(bool sink) {

6    sink = my_trait<char>::value || my_trait<int>::value;  // no-warning, awesome

7    sink = my_trait<char>::value || my_trait<char>::value; // no warning for this either :(

8    return sink;

9  }


How is it possible to have different NestedNameSpecifier pointers describing the same thing?

Am I missing something?

 

Thanks,

Balázs



From: David Rector <davrecthreads at gmail.com> 
Sent: 2021. november 23., kedd 23:39
To: Benics Balázs <benicsbalazs at gmail.com>
Cc: cfe-dev <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] Same AST for is_same<char, int>::value and is_same<char, long>::value

 

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





On Nov 23, 2021, at 11:03 AM, Benics Balázs via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> > wrote:

 

(Resending from my personal email address)

 

 

  _____  

From: Balázs Benics <balazs.benics at sigmatechnology.se <mailto:balazs.benics at sigmatechnology.se> >
Sent: Tuesday, November 23, 2021, 14:45
To: cfe-dev
Subject: Same AST for is_same::value and is_same::value



 

I seek some advice on the following AST scenario.

https://godbolt.org/z/WcTeoGcbG

 

1  #include <type_traits>

2  using std::is_same;

3  bool top() {

4    return is_same<char, int>::value || is_same<char, long>::value;

5  }

 

The `alpha.core.IdenticalExpr` static analyzer checker warns about that the two `..::value` are identical DeclRefExprs.

According to the AST, they are indeed identical:

 

  BinaryOperator <col:10, col:60> 'bool' '||'

  |-ImplicitCastExpr <col:10, col:30> 'bool':'bool' <LValueToRValue>

  | `-DeclRefExpr <col:10, col:30> 'const bool':'const bool' lvalue Var 0x563b67cde0a8 'value' 'const bool':'const bool'

  `-ImplicitCastExpr <col:39, col:60> 'bool':'bool' <LValueToRValue>

    `-DeclRefExpr <col:39, col:60> 'const bool':'const bool' lvalue Var 0x563b67cde0a8 'value' 'const bool':'const bool'

 

Both of them refers to the same `VarDecl`, corresponding (probably) to the `std::false_type::value`.

 

How can I detect that even though the `values` look similar, they correspond to different template instances in that sense?

What do you suggest?

In the end, I want to suppress these reports in the static analyzer.

 

Balázs

 

_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org <mailto: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/20211124/038da82a/attachment.html>