llvm-svn: 152013

kinds as the underlying string literals, and we silently drop the ud-suffix;
those issues will be fixed by subsequent patches.

llvm-svn: 152012

Remove a recursive visitation in ExprEngine that is no longer needed because the CFG is fully linearized.

llvm-svn: 152007

llvm-svn: 151997

we're making.  We only ignore implicit casts.  Add a testcase showing that
we get the right behavior with explicit casts.

llvm-svn: 151994

reported by Richard Smith.

llvm-svn: 151993

llvm-svn: 151992

[analyzer] do not warn about returning stack-allocated memory when it comes from an ancestor stack frame.

llvm-svn: 151964

llvm-svn: 151956

scalar emission of DeclRefExprs to const bools: emit scalar bools as i1,
not as i8.

In addition to the extra unit testing, this has successfully bootstrapped.

llvm-svn: 151955

llvm-svn: 151951

llvm-svn: 151949

llvm-svn: 151947

GNU attributes to a better extent, by allowing them in more
places on a declator.

llvm-svn: 151945

llvm-svn: 151944

It doesn't warn if the integer is known at compile time and within
the bounds of the string.

Discussion: http://comments.gmane.org/gmane.comp.compilers.clang.scm/47203
llvm-svn: 151943

issue the note if it is because message is sent to a forward class
declaration in delayed diagnostic. // rdar://10290322

llvm-svn: 151942

Fixes <rdar://problem/10967815>

llvm-svn: 151938

ptrdiff_t on PPC32 on Linux, etc. should be int not long.
This does not matter for C, but it does matter for C++ because of
name mangling.

The preprocessor test has been changed accordingly.

llvm-svn: 151935

This is consistent with -Wbool-conversion. Let me know if you prefer
a different flag name.

llvm-svn: 151934

@class I;
@implementation I(cat) // crashes here
@end

rdar://10968158

llvm-svn: 151931

command line options for inlining tuning.

This adds the option for stack depth bound as well as function size
bound. 

+ minor doxygenification

llvm-svn: 151930

// rdar://10961370

llvm-svn: 151923

Revert r151879, r151880, "PR12145: Avoid emitting loads of constexpr variables in contexts where there" and "Fix buildbot: make this test less dependent on the value names in the produced IR."

They broke bootstrap.

llvm-svn: 151922

early, since their values can be used in constant expressions in C++11. For
odr-use checking, the opposite change is required, since references are
odr-used whether or not they satisfy the requirements for appearing in a
constant expression.

llvm-svn: 151881

llvm-svn: 151880

is no odr-use of the variable. Go slightly beyond what the standard requires
for variables of reference type.

llvm-svn: 151879

[analyzer diagnostics] Change CompactPathDiagnostic to recursively compact diagnostics in calls into macro pieces.
Also fix handling of macros within calls in the HTMLDiagnostics.

This also adds a test case for r151774.

llvm-svn: 151872

But it is in the underlying c part of clang. clang crashes
in IRGen when passing an incomplete type argument to 
variadic function (instead of diagnosing the bug).
// rdar://10961370

llvm-svn: 151862

llvm-svn: 151853

shouldn't be relying on assembly emission.

For the record we should check the metadata output from the front
end and then check in the backend that such a thing emits a pubtypes
entry.

llvm-svn: 151851

Fix a test, which was most likely an unintended recursive call.

llvm-svn: 151848

This flag enables ThreadSanitizer instrumentation committed to llvm as r150423.
The patch includes one test for -fthread-sanitizer and one similar test for -faddress-sanitizer.
This patch does not modify the linker flags (as we do it for -faddress-sanitizer) because the run-time library is not yet
committed and it's structure in compiler-rt is not 100% clear.
The users manual wil be changed in a separate commit.

llvm-svn: 151846

Change @import to @__experimental_modules_import.  We are not ready to commit to a particular syntax for modules,
and don't have time to push it forward in the near future.

llvm-svn: 151841

attributes, introduced in r151188.

+ the test to catch it.

Thanks to Ahmed Charles for pointing this out.

llvm-svn: 151840

correctly.

Still rdar://10900684

llvm-svn: 151838

llvm-svn: 151837

Will bring it up once the issue is fixed properely.

llvm-svn: 151830

llvm-svn: 151819

llvm-svn: 151812