[clang] Change std::sort to llvm::sort in response to r327219

r327219 added wrappers to std::sort which randomly shuffle the container before
sorting. This will help in uncovering non-determinism c

[clang] Change std::sort to llvm::sort in response to r327219

r327219 added wrappers to std::sort which randomly shuffle the container before
sorting. This will help in uncovering non-determinism caused due to undefined
sorting order of objects having the same key.

To make use of that infrastructure we need to invoke llvm::sort instead of
std::sort.

llvm-svn: 328636

show more ...

Re-commit r321223, which adds a printing policy to the ASTDumper.

This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct o

Re-commit r321223, which adds a printing policy to the ASTDumper.

This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms.

Fixes the -Wreorder issue and fixes the ast-dump-color.cpp test.

llvm-svn: 321310

show more ...

Reverting r321223 and its follow-up commit because of failing bots due to Misc/ast-dump-color.cpp.

llvm-svn: 321229

Add a printing policy to the ASTDumper.

This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C

Add a printing policy to the ASTDumper.

This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms.

llvm-svn: 321223

show more ...

StaticAnalyzer: Report found fields order in PaddingChecker

Report the found fields order in PaddingChecker.

Patch by Alexander Shaposhnikov!

llvm-svn: 278730

StaticAnalyzer: Avoid an unintentional copy

The range here isn't over references, so using `auto &` here incites a
copy. Switching to `auto *` would do, but we might as well list an
explicit type fo

StaticAnalyzer: Avoid an unintentional copy

The range here isn't over references, so using `auto &` here incites a
copy. Switching to `auto *` would do, but we might as well list an
explicit type for clarity.

Found by -Wrange-loop-analysis.

llvm-svn: 264071

show more ...

Update for LLVM function name change.

llvm-svn: 257802

[PATCH] Adding checker to detect excess padding in records

The intent of this checker is to generate a report for any class / structure
that could reduce its padding by reordering the fields. This

[PATCH] Adding checker to detect excess padding in records

The intent of this checker is to generate a report for any class / structure
that could reduce its padding by reordering the fields. This results in a very
noisy checker. To reduce the noise, this checker will currently only warn when
the number of bytes over "optimal" is more than 24. This value is configurable
with -analyzer-config performance.Padding:AllowedPad=N. Small values of
AllowedPad have the potential to generate hundreds of reports, and gigabytes
of HTML reports.

The checker searches for padding violations in two main ways. First, it goes
record by record. A report is generated if the fields could be reordered in a
way that reduces the padding by more than AllowedPad bytes. Second, the
checker will generate a report if an array will cause more than AllowedPad
padding bytes to be generated.

The record checker currently skips many ABI specific cases. Classes with base
classes are skipped because base class tail padding is ABI specific. Bitfields
are just plain hard, and duplicating that code seems like a bad idea. VLAs are
both uncommon and non-trivial to fix.

The array checker isn't very thorough right now. It only checks to see if the
element type's fields could be reordered, and it doesn't recursively check to
see if any of the fields' fields could be reordered. At some point in the
future, it would be nice if "arrays" could also look at array new usages and
malloc patterns that appear to be creating arrays.

llvm-svn: 255545

show more ...