Commit Graph

8 Commits

Author SHA1 Message Date
Mandeep Singh Grang a4c6f25016 [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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@328636 91177308-0d34-0410-b5e6-96231b3b80d8
2018-03-27 16:50:00 +00:00
Aaron Ballman fcc28fd8cc 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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321310 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-21 21:42:42 +00:00
Aaron Ballman 0752e75d9b Reverting r321223 and its follow-up commit because of failing bots due to Misc/ast-dump-color.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321229 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-20 23:17:29 +00:00
Aaron Ballman bfdec8d00b 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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321223 91177308-0d34-0410-b5e6-96231b3b80d8
2017-12-20 22:04:54 +00:00
Saleem Abdulrasool 54ed545ebf StaticAnalyzer: Report found fields order in PaddingChecker
Report the found fields order in PaddingChecker.

Patch by Alexander Shaposhnikov!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278730 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-15 20:16:13 +00:00
Justin Bogner 9872ddf47c 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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264071 91177308-0d34-0410-b5e6-96231b3b80d8
2016-03-22 17:50:05 +00:00
Rui Ueyama 9e83128d12 Update for LLVM function name change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257802 91177308-0d34-0410-b5e6-96231b3b80d8
2016-01-14 21:00:27 +00:00
Ben Craig 1b26d93e5d [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.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@255545 91177308-0d34-0410-b5e6-96231b3b80d8
2015-12-14 21:38:59 +00:00