It reduces the amount of emitted debug information:
1) DIEs in .debug_info have types DW_TAG_compile_unit, DW_TAG_subprogram,
DW_TAG_inlined_subroutine (for opt builds) and DW_TAG_lexical_block only.
2) .debug_str contains only function names.
3) No debug data for types/namespaces/variables is emitted.
4) The data in .debug_line is enough to produce valid stack traces with
function names and line numbers.

Reviewed by Eric Christopher.

llvm-svn: 156160

llvm-svn: 156149

in the conditional.

llvm-svn: 156148

rdar://11353109

llvm-svn: 156145

a struct.

llvm-svn: 156135

(Since we don't have a generic pointer escape callback, modify
ExprEngineCallAndReturn as well as the malloc checker.)

llvm-svn: 156134

of templates by using the newly introduce FoldingSetVector. This
preserves insertion order for all iteration of specializations.

I've also included a somewhat terrifying testcase that rapidly builds up
a large number of functions. This is enough that any system with ASLR
will have non-deterministic debug information generated for the test
case without the fix here as the debug information is generated in part
by walking these specializations.

llvm-svn: 156133

Inline DenseMapInfo<clang::DeclarationName>::getHashValue() for a 0.4% speedup on <rdar://problem/11004361>

llvm-svn: 156129

// rdar://11095151

llvm-svn: 156127

(trivially) make DeclContext::lookup()'s const version inlinable. Good
for 0.3% on <rdar://problem/11004361>.

llvm-svn: 156126

synthesis translation. // rdar://11374235 - wip.

llvm-svn: 156125

llvm-svn: 156123

array_lengthof.  Also, append the new filename with correct preprocessed suffix.
Last part of rdar://11285725

llvm-svn: 156117

dropped its prior behavior of always defining __cplusplus to 1 in GNU mode in
version 4.7.

llvm-svn: 156113

validate that we didn't override the contents of any of such files.

If this is detected, emit a diagnostic error and recover gracefully
by using the contents of the original file that the PCH was built from.

Part of rdar://11305263

llvm-svn: 156107

of places. // rdar://11375908

llvm-svn: 156106

llvm-svn: 156104

performing the search for overridden methods. We very rarely see the
same container twice, and in those rare cases we still have the
fallback of the second SmallPtrSet to eliminate duplicates. Good for
~1.5% -fsyntax-only speedup on the code in <rdar://problem/11004361>.

llvm-svn: 156103

prototypes should both return  `struct objc_class *`.
// rdar://11375495

llvm-svn: 156097

Part of rdar://11285725

llvm-svn: 156096

llvm-svn: 156093

Some of the NSAssert macros in OS X 10.7 are implemented in a way that
adds extra arguments that trigger the -Wformat-extra-args warning.
Earlier versions of clang failed to detect those -Wformat issues, but now
that clang is reporting those problems, we need to quiet them since there's
nothing to be done to fix them.  <rdar://problem/11317765>

I don't know how to write a testcase for this.  Suggestions welcome.
Patch by Ted Kremenek!

llvm-svn: 156092

llvm-svn: 156091

[analyzer] When promoting constant integers in a comparison, use the larger width of the two to avoid truncation.

llvm-svn: 156089

cases in switch statements. Also add a [[clang::fallthrough]] attribute, which
can be used to suppress the warning in the case of intentional fallthrough.

Patch by Alexander Kornienko!

The handling of C++11 attribute namespaces in this patch is temporary, and will
be replaced with a cleaner mechanism in a subsequent patch.

llvm-svn: 156086

specifically checks for equality to null.

Enforcing this general practice, which keeps the analyzer less
noisy, in the CString Checker. This change suppresses "Assigned value is
garbage or undefined" warning in the added test case.

llvm-svn: 156085

failing to lex the string, as suggested by Eli.

Part of rdar://11305263.

llvm-svn: 156081

aren't necessary to reproduce the clang crash.
Part of rdar://11285725

llvm-svn: 156079

under -Wobjc-missing-property-synthesis which must be
opted-in. // rdar://11295716

llvm-svn: 156078

llvm-svn: 156074

[analyzer] Equality ops are like relational ops in that the arguments shouldn't be converted to the result type. Fixes PR12206 and dupe PR12510.

This was probably the original intent of r133041 (also me, a year ago).

llvm-svn: 156062

llvm-svn: 156058

Fixes rdar://11353109 & http://llvm.org/bugs/show_bug.cgi?id=12689

llvm-svn: 156056

We need to identify the value of ptr as
ElementRegion (result of pointer arithmetic) in the following code.
However, before this commit '(2-x)' evaluated to Unknown value, and as
the result, 'p + (2-x)' evaluated to Unknown value as well.

int *p = malloc(sizeof(int));
ptr = p + (2-x);

llvm-svn: 156052

The resulting type info is stored in the SymSymExpr, so no reason not to
support construction of expression with different subexpression types.

llvm-svn: 156051

(Currently, this is only relevant for tainted data.)

llvm-svn: 156050

The change resulted in multiple issues on the buildbot, so it's not
ready for prime time. Only enable history tracking for tainted
data(which is experimental) for now.

llvm-svn: 156049

#define TEST int y; int x = y;
void foo() {
  TEST
}

-Wuninitialized gives this warning:
invalid-loc.cc:4:3: warning: variable 'y' is uninitialized when used here
      [-Wuninitialized]
  TEST
  ^~~~
invalid-loc.cc:2:29: note: expanded from macro 'TEST'
#define TEST int y; int x = y;
                            ^
note: initialize the variable 'y' to silence this warning
1 warning generated.

The second note lacks filename, line number, and code snippet.  This change
will remove the fixit and only point to variable declaration.

invalid-loc.cc:4:3: warning: variable 'y' is uninitialized when used here
      [-Wuninitialized]
  TEST
  ^~~~
invalid-loc.cc:2:29: note: expanded from macro 'TEST'
#define TEST int y; int x = y;
                            ^
invalid-loc.cc:4:3: note: variable 'y' is declared here
  TEST
  ^
invalid-loc.cc:2:14: note: expanded from macro 'TEST'
#define TEST int y; int x = y;
             ^
1 warning generated.

llvm-svn: 156045

not as we expect; it may be due to racing issue of a file coming from PCH
changing after the PCH is loaded.

rdar://11353109

llvm-svn: 156043

for __NSContainer_literal.

llvm-svn: 156035