[analyzer][NFC] Take SVal and NonLoc by value

[analyzer][UninitializedObjectChecker] PR41741: Regard all scalar types as primitive.

https://bugs.llvm.org/show_bug.cgi?id=41741

Pretty much the same as D61246 and D61106, this time for __complex_

[analyzer][UninitializedObjectChecker] PR41741: Regard all scalar types as primitive.

https://bugs.llvm.org/show_bug.cgi?id=41741

Pretty much the same as D61246 and D61106, this time for __complex__ types. Upon
further investigation, I realized that we should regard all types
Type::isScalarType returns true for as primitive, so I merged
isMemberPointerType(), isBlockPointerType() and isAnyComplexType()` into that
instead.

I also stumbled across yet another bug,
https://bugs.llvm.org/show_bug.cgi?id=41753, but it seems to be unrelated to
this checker.

Differential Revision: https://reviews.llvm.org/D61569

llvm-svn: 359998

show more ...

[analyzer][UninitializedObjectChecker] PR41611: Regard vector types as primitive

https://bugs.llvm.org/show_bug.cgi?id=41611

Similarly to D61106, the checker ran over an llvm_unreachable for vector

[analyzer][UninitializedObjectChecker] PR41611: Regard vector types as primitive

https://bugs.llvm.org/show_bug.cgi?id=41611

Similarly to D61106, the checker ran over an llvm_unreachable for vector types:

struct VectorSizeLong {
VectorSizeLong() {}
__attribute__((__vector_size__(16))) long x;
};

void __vector_size__LongTest() {
VectorSizeLong v;
}
Since, according to my short research,

"The vector_size attribute is only applicable to integral and float scalars,
although arrays, pointers, and function return values are allowed in conjunction
with this construct."
[src: https://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Vector-Extensions.html#Vector-Extensions]

vector types are safe to regard as primitive.

Differential Revision: https://reviews.llvm.org/D61246

llvm-svn: 359539

show more ...

[analyzer][UninitializedObjectChecker] PR41590: Regard _Atomic types as primitive

https://bugs.llvm.org/show_bug.cgi?id=41590

For the following code snippet, UninitializedObjectChecker crashed:

st

[analyzer][UninitializedObjectChecker] PR41590: Regard _Atomic types as primitive

https://bugs.llvm.org/show_bug.cgi?id=41590

For the following code snippet, UninitializedObjectChecker crashed:

struct MyAtomicInt {
_Atomic(int) x;
MyAtomicInt() {}
};

void entry() {
MyAtomicInt b;
}

The problem was that _Atomic types were not regular records, unions,
dereferencable or primitive, making the checker hit the llvm_unreachable at
lib/StaticAnalyzer/Checkers/UninitializedObject/UninitializedObjectChecker.cpp:347.
The solution is to regard these types as primitive as well. The test case shows
that with this addition, not only are we able to get rid of the crash, but we
can identify x as uninitialized.

Differential Revision: https://reviews.llvm.org/D61106

llvm-svn: 359230

show more ...

[analyzer] Move UninitializedObjectChecker out of alpha

Moved UninitializedObjectChecker from the 'alpha.cplusplus' to the
'optin.cplusplus' package.

Differential Revision: https://reviews.llvm.org

[analyzer] Move UninitializedObjectChecker out of alpha

Moved UninitializedObjectChecker from the 'alpha.cplusplus' to the
'optin.cplusplus' package.

Differential Revision: https://reviews.llvm.org/D58573

llvm-svn: 358797

show more ...

[analyzer][UninitializedObjectChecker] New flag to ignore guarded uninitialized fields

This patch is an implementation of the ideas discussed on the mailing list[1].

The idea is to somewhat heurist

[analyzer][UninitializedObjectChecker] New flag to ignore guarded uninitialized fields

This patch is an implementation of the ideas discussed on the mailing list[1].

The idea is to somewhat heuristically guess whether the field that was confirmed
to be uninitialized is actually guarded with ifs, asserts, switch/cases and so
on. Since this is a syntactic check, it is very much prone to drastically
reduce the amount of reports the checker emits. The reports however that do not
get filtered out though have greater likelihood of them manifesting into actual
runtime errors.

[1] http://lists.llvm.org/pipermail/cfe-dev/2018-September/059255.html

Differential Revision: https://reviews.llvm.org/D51866

llvm-svn: 352959

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Misc typos fixes in ./lib folder

Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned`

Reviewers: teemperor

Reviewed By: teemperor

Subs

Misc typos fixes in ./lib folder

Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned`

Reviewers: teemperor

Reviewed By: teemperor

Subscribers: teemperor, jholewinski, jvesely, nhaehnle, whisperity, jfb, cfe-commits

Differential Revision: https://reviews.llvm.org/D55475

llvm-svn: 348755

show more ...

[analyzer][UninitializedObjectChecker] Uninit regions are only reported once

Especially with pointees, a lot of meaningless reports came from uninitialized
regions that were already reported. This i

[analyzer][UninitializedObjectChecker] Uninit regions are only reported once

Especially with pointees, a lot of meaningless reports came from uninitialized
regions that were already reported. This is fixed by storing all reported fields
to the GDM.

Differential Revision: https://reviews.llvm.org/D51531

llvm-svn: 347153

show more ...

Revert "[Lex] TokenConcatenation now takes const Preprocessor"

This reverts commit r344262. This was an unintentional commit.

llvm-svn: 344267

[Lex] TokenConcatenation now takes const Preprocessor

Differential Revision: https://reviews.llvm.org/D52502

llvm-svn: 344262

Revert untintentionally commited changes

llvm-svn: 343574

[Lex] TokenConcatenation now takes const Preprocessor

Differential Revision: https://reviews.llvm.org/D52502

llvm-svn: 343573

Revert untintentionally commited changes

llvm-svn: 343205

[Lex] TokenConcatenation now takes const Preprocessor

Differential Revision: https://reviews.llvm.org/D52502

llvm-svn: 343204

[analyzer][UninitializedObjectChecker] Using the new const methods of ImmutableList

Differential Revision: https://reviews.llvm.org/D51886

llvm-svn: 342834

[analyzer][UninitializedObjectChecker] New flag to ignore records based on it's fields

Based on a suggestion from @george.karpenkov.

In some cases, structs are used as unions with a help of a tag/k

[analyzer][UninitializedObjectChecker] New flag to ignore records based on it's fields

Based on a suggestion from @george.karpenkov.

In some cases, structs are used as unions with a help of a tag/kind field.
This patch adds a new string flag (a pattern), that is matched against the
fields of a record, and should a match be found, the entire record is ignored.

For more info refer to http://lists.llvm.org/pipermail/cfe-dev/2018-August/058906.html
and to the responses to that, especially http://lists.llvm.org/pipermail/cfe-dev/2018-August/059215.html.

Differential Revision: https://reviews.llvm.org/D51680

llvm-svn: 342220

show more ...

[analyzer][UninitializedObjectChecker] Refactored checker options

Since I plan to add a number of new flags, it made sense to encapsulate
them in a new struct, in order not to pollute FindUninitiali

[analyzer][UninitializedObjectChecker] Refactored checker options

Since I plan to add a number of new flags, it made sense to encapsulate
them in a new struct, in order not to pollute FindUninitializedFields's
constructor with new boolean options with super long names.

This revision practically reverts D50508, since FindUninitializedFields
now accesses the pedantic flag anyways.

Differential Revision: https://reviews.llvm.org/D51679

llvm-svn: 342219

show more ...

[analyzer][UninitializedObjectChecker] Updated comments

Some of the comments are incorrect, imprecise, or simply nonexistent.
Since I have a better grasp on how the analyzer works, it makes sense
to

[analyzer][UninitializedObjectChecker] Updated comments

Some of the comments are incorrect, imprecise, or simply nonexistent.
Since I have a better grasp on how the analyzer works, it makes sense
to update most of them in a single swoop.

I tried not to flood the code with comments too much, this amount
feels just right to me.

Differential Revision: https://reviews.llvm.org/D51417

llvm-svn: 342215

show more ...

[analyzer][UninitializedObjectChecker] Fixed dereferencing

iThis patch aims to fix derefencing, which has been debated for months now.

Instead of working with SVals, the function now relies on Type

[analyzer][UninitializedObjectChecker] Fixed dereferencing

iThis patch aims to fix derefencing, which has been debated for months now.

Instead of working with SVals, the function now relies on TypedValueRegion.

Differential Revision: https://reviews.llvm.org/D51057

llvm-svn: 342213

show more ...

[analyzer][UninitializedObjectChecker] Explicit namespace resolution for inherited data members

For the following example:

struct Base {
int x;
};

// In a different translation unit

s

[analyzer][UninitializedObjectChecker] Explicit namespace resolution for inherited data members

For the following example:

struct Base {
int x;
};

// In a different translation unit

struct Derived : public Base {
Derived() {}
};

For a call to Derived::Derived(), we'll receive a note that
this->x is uninitialized. Since x is not a direct field of Derived,
it could be a little confusing. This patch aims to fix this, as well
as the case when the derived object has a field that has the name as
an inherited uninitialized data member:

struct Base {
int x; // note: uninitialized field 'this->Base::x'
};

struct Derived : public Base {
int x = 5;
Derived() {}
};

Differential Revision: https://reviews.llvm.org/D50905

llvm-svn: 340272

show more ...

[NFC] Don't define static function in header (UninitializedObject.h)

Summary:
See also http://lists.llvm.org/pipermail/cfe-users/2016-January/000854.html for
the reasons why it's bad.

Reviewers: Sz

[NFC] Don't define static function in header (UninitializedObject.h)

Summary:
See also http://lists.llvm.org/pipermail/cfe-users/2016-January/000854.html for
the reasons why it's bad.

Reviewers: Szelethus, erichkeane

Reviewed By: Szelethus

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D50963

llvm-svn: 340174

show more ...

Fix Clang warnings and bad #include filenames in r339595 and r339599.

llvm-svn: 339624

[analyzer][UninitializedObjectChecker] Refactoring p5.: Handle pedantic mode in the checker class only

Differential Revision: https://reviews.llvm.org/D50508

llvm-svn: 339601

[analyzer][UninitializedObjectChecker] Refactoring p4.: Wrap FieldRegions and reduce weight on FieldChainInfo

Before this patch, FieldChainInfo used a spaghetti: it took care of way too many cases,

[analyzer][UninitializedObjectChecker] Refactoring p4.: Wrap FieldRegions and reduce weight on FieldChainInfo

Before this patch, FieldChainInfo used a spaghetti: it took care of way too many cases,
even though it was always meant as a lightweight wrapper around
ImmutableList<const FieldRegion *>.
This problem is solved by introducing a lightweight polymorphic wrapper around const
FieldRegion *, FieldNode. It is an interface that abstracts away special cases like
pointers/references, objects that need to be casted to another type for a proper note
messages.

Changes to FieldChainInfo:

* Now wraps ImmutableList<const FieldNode &>.
* Any pointer/reference related fields and methods were removed
* Got a new add method. This replaces it's former constructors as a way to create a
new FieldChainInfo objects with a new element.

Changes to FindUninitializedField:

* In order not to deal with dynamic memory management, when an uninitialized field is
found, the note message for it is constructed and is stored instead of a
FieldChainInfo object. (see doc around addFieldToUninits).

Some of the test files are changed too, from now on uninitialized pointees of references
always print "uninitialized pointee" instead of "uninitialized field" (which should've
really been like this from the beginning).

I also updated every comment according to these changes.

Differential Revision: https://reviews.llvm.org/D50506

llvm-svn: 339599

show more ...