Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""

It seems the two failing tests can be simply fixed after r348037

Fix 3 cases in Analysis/builtin-functions.cpp
Delete the

Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""

It seems the two failing tests can be simply fixed after r348037

Fix 3 cases in Analysis/builtin-functions.cpp
Delete the bad CodeGen/builtin-constant-p.c for now

llvm-svn: 348053

show more ...

Revert r347417 "Re-Reinstate 347294 with a fix for the failures."

Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp
while we are investigating why the fo

Revert r347417 "Re-Reinstate 347294 with a fix for the failures."

Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp
while we are investigating why the following snippet fails:

extern char extern_var;
struct { int a; } a = {__builtin_constant_p(extern_var)};

llvm-svn: 348039

show more ...

Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."

This was reverted in r347656 due to me thinking it caused a miscompile of
Chromium. Turns out it was the Chromium code that was b

Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."

This was reverted in r347656 due to me thinking it caused a miscompile of
Chromium. Turns out it was the Chromium code that was broken.

llvm-svn: 347756

show more ...

Revert r347417 "Re-Reinstate 347294 with a fix for the failures."

This caused a miscompile in Chrome (see crbug.com/908372) that's
illustrated by this small reduction:

static bool f(int *a, int *

Revert r347417 "Re-Reinstate 347294 with a fix for the failures."

This caused a miscompile in Chrome (see crbug.com/908372) that's
illustrated by this small reduction:

static bool f(int *a, int *b) {
return !__builtin_constant_p(b - a) || (!(b - a));
}

int arr[] = {1,2,3};

bool g() {
return f(arr, arr + 3);
}

$ clang -O2 -S -emit-llvm a.cc -o -

g() should return true, but after r347417 it became false for some reason.

This also reverts the follow-up commits.

r347417:
> Re-Reinstate 347294 with a fix for the failures.
>
> Don't try to emit a scalar expression for a non-scalar argument to
> __builtin_constant_p().
>
> Third time's a charm!

r347446:
> The result of is.constant() is unsigned.

r347480:
> A __builtin_constant_p() returns 0 with a function type.

r347512:
> isEvaluatable() implies a constant context.
>
> Assume that we're in a constant context if we're asking if the expression can
> be compiled into a constant initializer. This fixes the issue where a
> __builtin_constant_p() in a compound literal was diagnosed as not being
> constant, even though it's always possible to convert the builtin into a
> constant.

r347531:
> A "constexpr" is evaluated in a constant context. Make sure this is reflected
> if a __builtin_constant_p() is a part of a constexpr.

llvm-svn: 347656

show more ...

Re-Reinstate 347294 with a fix for the failures.

Don't try to emit a scalar expression for a non-scalar argument to
__builtin_constant_p().

Third time's a charm!

llvm-svn: 347417

Revert r347364 again, the fix was incomplete.

llvm-svn: 347389

Reinstate 347294 with a fix for the failures.

EvaluateAsInt() is sometimes called in a constant context. When that's the
case, we need to specify it as so.

llvm-svn: 347364

Change \t to spaces

llvm-svn: 337530

[analyzer] Add security checks for bcmp(), bcopy(), bzero().

These functions are obsolete. The analyzer would advice to replace them with
memcmp(), memcpy() or memmove(), or memset().

Patch by Tom

[analyzer] Add security checks for bcmp(), bcopy(), bzero().

These functions are obsolete. The analyzer would advice to replace them with
memcmp(), memcpy() or memmove(), or memset().

Patch by Tom Rix!

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

llvm-svn: 333326

show more ...

[analyzer] Don't flag strcpy of string literals into sufficiently large buffers.

In the security package, we have a simple syntactic check that warns about
strcpy() being insecure, due to potential

[analyzer] Don't flag strcpy of string literals into sufficiently large buffers.

In the security package, we have a simple syntactic check that warns about
strcpy() being insecure, due to potential buffer overflows.

Suppress that check's warning in the trivial situation when the source is an
immediate null-terminated string literal and the target is an immediate
sufficiently large buffer.

Patch by András Leitereg!

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

llvm-svn: 322410

show more ...

[CSA] [NFC] Move AnalysisContext.h to AnalysisDeclContext.h

The implementation is in AnalysisDeclContext.cpp and the class is called
AnalysisDeclContext.

Making those match up has numerous benefits

[CSA] [NFC] Move AnalysisContext.h to AnalysisDeclContext.h

The implementation is in AnalysisDeclContext.cpp and the class is called
AnalysisDeclContext.

Making those match up has numerous benefits, including:

- Easier jump from header to/from implementation.
- Easily identify filename from class.

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

llvm-svn: 312671

show more ...

Remove Bitrig: Clang Changes

Bitrig code has been merged back to OpenBSD, thus the OS has been abandoned.

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

llvm-svn: 308797

Test commit
Remove tabs.

llvm-svn: 254181

[analyzer] Apply whitespace cleanups by Honggyu Kim.

llvm-svn: 246978

Rewrite users of Stmt::child_begin/end into for-range loops.

No functionality change intended.

llvm-svn: 241355

Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").

llvm-svn: 240353

Fixed/added namespace ending comments using clang-tidy. NFC

The patch is generated using this command:

$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comme

Fixed/added namespace ending comments using clang-tidy. NFC

The patch is generated using this command:

$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang

To reduce churn, not touching namespaces spanning less than 10 lines.

llvm-svn: 240270

show more ...

Enable security checks for arc4random() on CloudABI as well.

CloudABI also supports the arc4random() function. We can enable compiler
warnings for rand(), random() and *rand48() on this system as we

Enable security checks for arc4random() on CloudABI as well.

CloudABI also supports the arc4random() function. We can enable compiler
warnings for rand(), random() and *rand48() on this system as well.

llvm-svn: 231914

show more ...

[C++11] Use 'nullptr'. StaticAnalyzer edition.

llvm-svn: 209642

Fix typos

llvm-svn: 208838

Expose the name of the checker producing each diagnostic message.

Summary:
In clang-tidy we'd like to know the name of the checker producing each
diagnostic message. PathDiagnostic has BugType and C

Expose the name of the checker producing each diagnostic message.

Summary:
In clang-tidy we'd like to know the name of the checker producing each
diagnostic message. PathDiagnostic has BugType and Category fields, which are
both arbitrary human-readable strings, but we need to know the exact name of the
checker in the form that can be used in the CheckersControlList option to
enable/disable the specific checker.

This patch adds the CheckName field to the CheckerBase class, and sets it in
the CheckerManager::registerChecker() method, which gets them from the
CheckerRegistry.

Checkers that implement multiple checks have to store the names of each check
in the respective registerXXXChecker method.

Reviewers: jordan_rose, krememek

Reviewed By: jordan_rose

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2557

llvm-svn: 201186

show more ...

Rename FunctionProtoType accessors from 'arguments' to 'parameters'

Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which argume

Rename FunctionProtoType accessors from 'arguments' to 'parameters'

Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.

Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.

Will keep an eye on the builders and update dependent projects shortly.

No functional change.

llvm-svn: 199686

show more ...

[analyzer] ArrayRef-ize BugReporter::EmitBasicReport.

No functionality change.

llvm-svn: 192114

Use getAs<> where appropriate on QualTypes instead of using dyn_cast.

llvm-svn: 184775

Check the canonical parameter type with getAs<>() in a static checker

This will prevent breakage when I introduce the DecayedType sugar node.

llvm-svn: 184755