Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

[clang-analyzer] False report about virtual method during construction #47451

Open Quuxplusone opened 3 years ago

Quuxplusone commented 3 years ago
Bugzilla Link PR48482
Status CONFIRMED
Importance P normal
Reported by Dmitry Polukhin (dmitry.polukhin@gmail.com)
Reported on 2020-12-11 04:17:50 -0800
Last modified on 2020-12-30 15:22:48 -0800
Version trunk
Hardware All All
CC balazs.benics@sigmatechnology.se, dcoughlin@apple.com, dkszelethus@gmail.com, llvm-bugs@lists.llvm.org, mtekieli@gmail.com, noqnoqneo@gmail.com, xazax.hun@gmail.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also
Minimal reproducer:

// clang++ --analyze -Xanalyzer -analyzer-output=text -Xanalyzer -analyzer-
checker='optin.cplusplus'

class Attribute {
public:
  virtual ~Attribute() = default;
  virtual int encode() const = 0;

 protected:
  Attribute() {}
};

class Number : public Attribute {
public:
  explicit Number()
      : Attribute() {}

  int encode() const override;

private:
  int number_;
};

void foo() {
  Number number;
  number.encode();
}

Output:
test.cpp:23:3: warning: Call to virtual method 'Number::encode' during
construction bypasses virtual dispatch
  number.encode();
  ^~~~~~~~~~~~~~~~~~~~~~
test.cpp:23:3: note: Call to virtual method 'Number::encode' during
construction bypasses virtual dispatch
  number.encode();
  ^~~~~~~~~~~~~~~~~~~~~~
1 warning generated.

To trigger this bug it is required to have uninitialised in c-tor member
`number_`. In full example the member was initialised later with member
function call before calling the virtual function. Problem exists starting from
at least clang 9 up to current trunk.
Quuxplusone commented 3 years ago

Uh-oh, yeah, this is clearly broken.

This false positive is caused by presence of a seemingly unrelated checker in your run-line, namely optin.cplusplus.UninitializedObject. If you explicitly disable this checker the false positive goes away.

Looks like one of the two checkers performs transitions incorrectly which causes a sudden state split near the exit from Number::Number.

Thanks for the bug report, I'll investigate further.

Quuxplusone commented 3 years ago

_Bug 48633 has been marked as a duplicate of this bug._

Quuxplusone commented 3 years ago

In https://bugs.llvm.org/show_bug.cgi?id=48633 there are a couple more examples of false positives in other checkers with the same root cause.