passing/receiving CF objects at +0 to/from Objective-C methods
or audited C functions.

llvm-svn: 142219

casts in ARC.

No semantic analysis yet.

llvm-svn: 142208

has placeholder type.

llvm-svn: 142203

in -fms-extensions mode, make sure we actually use that initializer
after having handled the declaration. Fixes PR11150.

llvm-svn: 142195

Richard already fixed the underlying issue, so the cast was superfluous.

llvm-svn: 142192

public. Add a __private_macro__ directive to hide a macro, similar to
the __module_private__ declaration specifier.

llvm-svn: 142188

as part of the hash rather than ignoring them. This means we'll end up
building more module variants (overall), but it allows configuration
macros such as NDEBUG to work so long as they're specified via command
line. More to come in this space.

llvm-svn: 142187

Fixed merge-mistake where ActOnAccessSpecifier was called twice for every access specifier. The testcase has been changed to catch this too.

llvm-svn: 142186

llvm-svn: 142179

llvm-svn: 142167

llvm-svn: 142160

end result. Use this split to propagate state information and diagnostics
through more of constant expression evaluation.

llvm-svn: 142159

llvm-svn: 142157

llvm-svn: 142148

This also applies to C99-style aggregate literals, should they be used in C++11, since they are effectively identical to constructor call list-initialization syntax.

llvm-svn: 142147

In the verify-only pass, check that items that don't have an initializer in an init list can be value-initialized, at least when designated initializers are not involved. No test case yet, since early failures cannot be distinguished from late failures until overload resolution works.

llvm-svn: 142146

llvm-svn: 142145

llvm-svn: 142144

Drop the Diagnose parameter from Sema::PerformImplicitConversion again and instead use TryImplicitConversion in CheckSingleAssignmentConstraints when that function is in no-diagnostics mode.

llvm-svn: 142143

Make a C-style cast a const-cast, to suppress a GCC warning. I should fix the underlying issue eventually, but this interface will probably change anyway.

llvm-svn: 142142

llvm-svn: 142138

llvm-svn: 142134

'libdir' mean the actual library directory, not the GCC subdirectory of
the library directory. That was just a confusing pattern. Instead,
supply proper GCC subdirectories when scanning for various triple-based
subdirectories with a GCC installation in them. This also makes it much
more obvious how multiarch installations, which have a triple-based
prefix as well as suffix work.

Also clean up our handling of these triple-prefixed trees by using them
in both a multiarch pattern and a non-multiarch pattern whenever they
exist.

Note that this *does not* match what GCC does on Debian, the only truly
multiarch installation I've been able to get installed and test on. GCC
appears to have a bug, and ends up searching paths like
'/lib/../../lib32' which makes no sense what-so-ever. Instead, I've
tried to encode the rational logic that seems clearly intended by GCC's
pattern. GCC ends up with patterns like:

  /lib/../../lib32
  /usr/lib/../../lib32
  /usr/lib/x86_64-linux-gnu/../..lib32

Only the last one makes any sense having a '/../..' in it, so in Clang,
that's the only one which gets a '/../..' in it.

I *think* this will fix Debian multiarch links. I'm committing without
baking this logic into our test suite so I can test on a few different
systems. If all goes well (and no one screams) I'll check in some more
comprehensive tests for multiarch behavior tomorrow.

llvm-svn: 142133

t.c:2:7: error: invalid operand for instruction
  asm("movl 0(%rax), 0(%edx)");
      ^
<inline asm>:1:16: note: instantiated into assembly here
        movl 0(%rax), 0(%edx)
                      ^~~~~~~
1 error generated.

llvm-svn: 142131

llvm-svn: 142129

function. No functionality changed.

llvm-svn: 142128

formatting as any other diagnostic, they will be properly line wrapped and
otherwise pretty printed. Let's take advantage of that and the new factoring to
add some helpful information to them (much like template backtrace notes and
other notes): the name of the macro whose expansion is being noted. This makes
a world of difference if caret diagnostics are disabled, making the expansion
notes actually useful in this case. It also helps ensure that in edge cases the
information the user needs is present. Consider:

% nl -ba t5.cc
     1  #define M(x, y, z) \
     2    y
     3
     4  M(
     5    1,
     6    2,
     7    3);

We now produce:
% ./bin/clang -fsyntax-only t5.cc
t5.cc:6:3: error: expected unqualified-id
  2,
  ^
t5.cc:2:3: note: expanded from macro: M
  y
  ^
1 error generated.

Without the added information in the note, the name of the macro being expanded
would never be shown.

This also deletes a FIXME to use the diagnostic formatting. It's not yet clear
to me that we *can* do this reasonably, and the production of this message was
my primary goal here anyways.

I'd love any comments or suggestions on improving these notes, their wording,
etc. Currently, I need to make them provide more helpful information in the
presence of a token-pasting buffer, and I'm pondering adding something along
the lines of "expanded from argument N of macro: ...".

llvm-svn: 142127

this long quest: actually use the note printing machinery for each macro
expansion note rather than a hacky version of it. This will colorize and
format the notes the same as any other. There is still some stuff to fix
here, but it's one step closer.

No test case changes because currently we don't do anything differently
that I can FileCheck for -- I don't really want to try matching the
color escape codes... Suggestions for how to test this are welcome. =]

llvm-svn: 142121

standing deficiency: we were providing no macro backtrace information
whenever caret diagnostics were turned off. This sinks the logic for
suppressing the code snippet and caret to the code that actually prints
tho code snippet and caret. Along the way, clean up the naming of
functions, remove some now fixed FIXMEs, and generally improve the
wording and logic of this process.

Add a test case exerecising this functionality. It is notable that the
resulting messages are extremely low quality. I'm working on a follow-up
patch that should address this and have left a FIXME in the test case.

llvm-svn: 142120

backtrace behavior.

llvm-svn: 142119

the important code in this test to make the test more stable. Now adding
further tests won't shift the line numbers occuring in the diagnostic
output.

llvm-svn: 142118

tests to it to cover more of the macro bactrace functionality.

llvm-svn: 142116

llvm-svn: 142113

llvm-svn: 142109

the SourceManager doesn't change, and the source files don't change.
This greatly simplifies the interfaces and interactions. The lifetime of
the TextDiagnostic object forms the 'session' over which we attempt to
condense and deduplicate information in diagnostics.

llvm-svn: 142104

function) to agree with the coding conventions, and in one case have
a bit more information in it.

llvm-svn: 142088

been there. Also delete their redundant doxyments in favor of those in
the source file. I'm putting the doxyments for private and static
helpers into the implementation file, and only the public interface
doxyments into the header. If folks have strong opinions about this type
of split, feel free to chime in, I'm happy to re-organize.

llvm-svn: 142087

making it accessible to anyone from the Frontend library. Still a good
bit of cleanup to do here, but its a good milestone. This ensures that
*all* of the functionality needed to implement the DiagnosticConsumer is
exposed via the generic interface in some form. No sneaky re-use of
static functions.

llvm-svn: 142086

part of the TextDiagnostic interface without requiring a full instance.

llvm-svn: 142085

allow the TextDiagnosticPrinter to continue using it even if
TextDiagnostic is implemented in a separate file.

llvm-svn: 142084