This is an archive of the discontinued LLVM Phabricator instance.

Add extension to always default-initialize nullptr_t.
ClosedPublic

Authored by erichkeane on Oct 25 2018, 9:44 AM.

Details

Summary

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
conversions from nullptr_t be equal to nullptr.

However, just implementing that results in warnings/etc in many places.
In order to fix all situations where nullptr_t would seem uninitialized,
this patch instead (as an otherwise transparent extension) default
initializes uninitialized VarDecls of nullptr_t.

Diff Detail

Repository
rC Clang

Event Timeline

erichkeane created this revision.Oct 25 2018, 9:44 AM

Woops, apparently a couple of tests fail on this that I somehow missed the 1st time. Looking into it.

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, but seems to be exactly what I'm suggesting as an extension here.

Is there any feedback here? Am I just completely incorrect in how I tried to fix this?

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 the question should still be asked.

NoQ accepted this revision.Dec 14 2018, 12:47 PM

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 show up on other compilers is generally less important than behaving similarly to Clang itself.

This revision is now accepted and ready to land.Dec 14 2018, 12:47 PM
This revision was automatically updated to reflect the committed changes.

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 example, given

alignas(nullptr_t) char buffer[sizeof(nullptr_t)];
nullptr_t *p = (nullptr_t*)buffer;
nullptr_t q = *p;

... there is no uninitialized use, but this patch will do nothing to make static analysis (etc) aware of that.

I think the real problem here is that our AST representation is wrong. We use CK_LValueToRValue to model a read from memory, but we also use it in examples like the above where there is no read from memory.

test/Analysis/nullptr.cpp
136

This bug is already fixed in trunk.

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

rsmith added inline comments.Dec 14 2018, 2:59 PM
test/Analysis/nullptr.cpp
136

Never mind, the fix was reverted in r346065.