llvm-svn: 186027

[objc-arc] Changed 'mode: c++' => 'C++' at Nick Lewycky's suggestion. Also removed unnecessary mode: c++ lines from .cpp files.

llvm-svn: 186026

llvm-svn: 186025

use/maintain additional state from the LambdaExpr while visiting the body
of a LambdaExpr.

One use for this arises because Clang's AST currently holds lambda bodies
in a form prior to their adjustment to refer to captured copies of local
variables, and so some clients will need access to the lambda's closure
type in order to query how to map VarDecl*s to the FieldDecls of their
by-copy captures. This hook is sufficient for at least one such client;
to do this without such a hook would require the client to re-implement
the whole of TraverseLambdaExpr, which is non-trivial and would likely be
more brittle.

llvm-svn: 186024

llvm-svn: 186023

llvm-svn: 186022

Found by -Wdocumentation.

llvm-svn: 186021

Fixed an issue introduced with my last fix where the command and sequence ID extraction were moved causing them to be reversed.

llvm-svn: 186020

Patch courtesy of Luke Zarko <zarko@google.com>

llvm-svn: 186019

llvm-svn: 186018

llvm-svn: 186017

The status function is already using a syscall that returns the file size.
Remember it and implement file_size as a simple wrapper.

No functionally change, but clients that already use status now can avoid
calling file_size.

llvm-svn: 186016

llvm-svn: 186015

llvm-svn: 186014

llvm-svn: 186013

Enough for the radeonsi driver to use it for calculating derivatives.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186012

lit test coverage to follow in the next commit.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186011

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186010

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186009

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186008

This patch is in preparation for writing the header replacement to disk.
Added getUniqueHeaderName() that generates a unique header filename in
the same directory as the header file.

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

llvm-svn: 186007

llvm-svn: 186006

In discussing this change with Bill Schmidt, it was decided that the original
comment about negative FIs was incorrect. We'll still exclude them for now, but
now with a more-accurate explanation.

llvm-svn: 186005

llvm-svn: 186004

This is not activated for any style, might change or go away
completely.

For those that want to play around with it, set
ExperimentalAutoDetectBinPacking to true.

clang-format will then:
Look at whether function calls/declarations/definitions are currently
formatted with one parameter per line (on a case-by-case basis). If so,
clang-format will avoid bin-packing the parameters. If all parameters
are on one line (thus that line is "inconclusive"), clang-format will
make the choice dependent on whether there are other bin-packed
calls/declarations in the same file.

The reason for this change is that bin-packing in some situations can be
really bad and an author might opt to put one parameter on each line. If
the author does that, he might want clang-format not to mess with that.
If the author is unhappy with the one-per-line formatting, clang-format
can easily be convinced to bin-pack by putting any two parameters on the
same line.

llvm-svn: 186003

llvm-svn: 186002

llvm-svn: 186001

llvm-svn: 186000

llvm-svn: 185999

directory stream, the entry is not written to, instead *result is set to
NULL and the entry is not written to at all.

I'm still somewhat suspicious of the correct instrumention here --
I feel like it should be marking the written range as the pointer in
*result and the length (*result)->d_reclen in case the implementation
decides not to use the passed-in entry (if that's even allowed).
Finally, the definition of 'struct dirent' analog used in the
interceptor is wrong in 32-bit mode with _FILE_OFFSET_BITS=64 as it hard
codes the use of a pointer-sized offset.

I've added a somewhat goofy test for the bug I fixed via ASan --
suggestions on how to better test the interceptor logic itself welcome.

llvm-svn: 185998

llvm-svn: 185997

<rdar://problem/14391836>

llvm-svn: 185996

llvm-svn: 185995

Currently ARM is the only backend that supports FMA instructions (for at least some subtargets) but does not implement this virtual, so FMAs are never generated except from explicit fma intrinsic calls. Apparently this is due to the fact that it supports both fused (one rounding step) and unfused (two rounding step) multiply + add instructions. This patch clarifies that this the case without changing behavior by implementing the virtual function to simply return false, as the default TargetLoweringBase version does.

It is possible that some cpus perform the fused version faster than the unfused version and vice-versa, so the function implementation should be revisited if hard data is found.

llvm-svn: 185994

Pulled in a testcase from the debuginfo-test suite.

llvm-svn: 185993

llvm-svn: 185992

Specifically, handle the case where the block is in a default argument
in a class method.  The mangling here follows what we do for lambdas.

llvm-svn: 185991

- ObjectFile::GetSymtab() and ObjectFile::ClearSymtab() no longer takes any flags
- Module coordinates with the object files and contain a unified section list so that object file and symbol file can share sections when they need to, yet contain their own sections.

Other cleanups:
- Fixed Symbol::GetByteSize() to not have the symbol table compute the byte sizes on the fly
- Modified the ObjectFileMachO class to compute symbol sizes all at once efficiently
- Modified the Symtab class to store a file address lookup table for more efficient lookups
- Removed Section::Finalize() and SectionList::Finalize() as they did nothing
- Improved performance of the detection of symbol files that have debug maps by excluding stripped files and core files, debug files, object files and stubs
- Added the ability to tell if an ObjectFile has been stripped with ObjectFile::IsStripped() (used this for the above performance improvement)

llvm-svn: 185990

llvm-svn: 185989

Fixed the CommunicationKDP::SendRequestAndGetReply() to correctly be able to deal with getting a reply from a previous packet without resending the packet again.

llvm-svn: 185988