rsmith added inline comments.
Comment at: test/Analysis/nullptr.cpp:136
-invokeF(p); // expected-warning{{1st function call argument is an
uninitialized value}}
-// expected-note@-1{{1st function call argument is an
uninitialized value}}
if (getSymbol())
erichkeane added a comment.
As stated in CFE commits (in response to Richard's comments):
`I’ll push a revert in a few minutes and give it another try. Perhaps I can
suppress the creation of a CK_LValueToRValue in the case where it’s a read from
nullptr_t
Repository:
rC Clang
CHANGES SINC
rsmith added a comment.
I'm concerned that this will hide real bugs by suppressing the bogus warnings
in (only) the simple cases. There is no "read a value from memory" operation on
type `nullptr_t` (just like for, say, class types), and any warning that
believes there is is incorrect. For exam
This revision was automatically updated to reflect the committed changes.
Closed by commit rC349201: Add extension to always default-initialize
nullptr_t. (authored by erichkeane, committed by ).
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D53713/new/
https://rev
NoQ accepted this revision.
NoQ added a comment.
This revision is now accepted and ready to land.
I approve this for Static Analyzer. As long as this is the correct thing to do
in the compiler, Static Analyzer should ideally behave similarly to the
compiler. Exposing portability bugs that would
aaron.ballman added reviewers: NoQ, george.karpenkov.
aaron.ballman added a comment.
Adding some reviewers for the static analyzer questions raised.
I think this is a reasonable approach, but are there situations where we should
diagnose this as an extension? I can't think of one, but I figured
erichkeane added a comment.
Is there any feedback here? Am I just completely incorrect in how I tried to
fix this?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D53713/new/
https://reviews.llvm.org/D53713
___
cfe-commits mailing list
cfe-c
erichkeane updated this revision to Diff 171128.
erichkeane added a comment.
Update the 2 failing tests. Would love some help looking at the Analysis fix,
it seems to no longer have to 'assume' stuff due to the this now being defined
behavior.
Additionally, the other test is just an AST change
erichkeane added a comment.
Woops, apparently a couple of tests fail on this that I somehow missed the 1st
time. Looking into it.
Repository:
rC Clang
https://reviews.llvm.org/D53713
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http:
erichkeane created this revision.
erichkeane added reviewers: rsmith, aaron.ballman.
Core issue 1013 suggests that having an uninitialied std::nullptr_t be
UB is a bit foolish, since there is only a single valid value. This DR
reports that DR616 fixes it, which does so by making lvalue-to-rvalue
c
10 matches
Mail list logo
