with debug info.]

Use CharUnits for the offsets in the VirtualBaseClassOffsetOffsetsMapTy. No
change in functionality intended.

llvm-svn: 129048

info.]

Use CharUnits for the offset type in the ClassNamesAndOffsets map in
dumpLayout(). No change in functionality intended.

llvm-svn: 129046

Use CharUnits for the offsets in the VBaseOffsetOffsetsMapTy types. No
change in functionality intended.

llvm-svn: 129043

so I'm killing it.

llvm-svn: 129026

llvm-svn: 129017

types such that protocols are seached first. Fixes
// rdar://9224670

llvm-svn: 129016

Patch by Bobby Powers

llvm-svn: 129014

llvm-svn: 129013

pass a previously failing clang test.
// rdar://8808439

llvm-svn: 129004

llvm-svn: 129001

llvm-svn: 129000

be sure to consume the argument index that actually had the attribute
rather than always the first.  rdar://problem/9234108

llvm-svn: 128998

llvm-svn: 128993

llvm-svn: 128987

Patch by Syoyo Fujita!  Reviewed by Chris Lattner!  Checked in by me!

llvm-svn: 128984

A situation where we can get an invalid ExprResult without an error.
Fixes PR8394.  Patch by Justin Bogner!

llvm-svn: 128979

within a token, like trigraphs and escaped newlines.               
Patch by Marcin Kowalczyk!

llvm-svn: 128978

llvm-svn: 128966

llvm-svn: 128957

As a result, I had to remove a c++ version of a clang
test which requires more scrutiny on my part.

llvm-svn: 128950

llvm-svn: 128948

llvm-svn: 128944

targets) when load/store results in multiple instructions.
// rdar://8808439

llvm-svn: 128937

marked explicitly as uninitialized through direct self initialization:

  int x = x;

With r128894 we prevented warnings about this code, and this patch
teaches the analysis engine to continue analyzing subsequent uses of
'x'. This should wrap up PR9624.

There is still an open question of whether we should suppress the
maybe-uninitialized warnings resulting from variables initialized in
this fashion. The definitely-uninitialized uses should always be warned.

llvm-svn: 128932

llvm-svn: 128928

llvm-svn: 128923

llvm-svn: 128921

Add security syntax checker for strcat() which causes the Static Analyzer to generate a warning any time the strcat() function is used with a note suggesting to use a function which provides bounded buffers. CWE-119.

Also, brings the security syntax checker more inline with coding standards.

llvm-svn: 128916

llvm-svn: 128915

developers can see if their driver changed any cl::Option's. The
current implementation isn't perfect but handles most kinds of
options. This is nice to have when decomposing the stages of
compilation and moving between different drivers. It's also a good
sanity check when comparing results produced by different command line
invocations that are expected to produce the comparable results.

Note: This is not an attempt to prolong the life of cl::Option. On the
contrary, it's a placeholder for a feature that must exist when
cl::Option is replaced by a more appropriate framework. A new
framework needs: a central option registry, dynamic name lookup,
non-global containers of option values (e.g. per-module,
per-function), *and* the ability to print options values and their defaults at
any point during compilation.

llvm-svn: 128911

llvm-svn: 128908

function more clear and obvious in behavior.

Add some comments documenting the behavior of the primary diagnostic helper.

llvm-svn: 128901

diagnostic emission. The fixit hint, when suggested, typically has
nothing to do with the nature or form of the reference.

llvm-svn: 128899

extracts a function to handle the emission of the diagnostic separately
from the walking over the set of uninitialized uses.

Also updates the naming used within this extracted function to be a bit
more consistent with the rest of Clang's naming patterns.

The next step will be breaking this apart so that we can go through
different functions rather than tracking so many boolean variables.

llvm-svn: 128898

llvm-svn: 128896

  int x = x;

GCC disables its warnings on this construct as a way of indicating that
the programmer intentionally wants the variable to be uninitialized.
Only the warning on the initializer is turned off in this iteration.

This makes the code a lot more ugly, but starts commenting the
surprising behavior here. This is a WIP, I want to refactor it
substantially for clarity, and to determine whether subsequent warnings
should be suppressed or not.

llvm-svn: 128894

llvm-svn: 128893

Does anyone want to buy me a new brain?

llvm-svn: 128890

of warnings when passing const arguments into the function.

Fixes PR9426

llvm-svn: 128880

I think this moves the code in the desired direction of the new style
recommendations (and style conventional in Clang), but if anyone prefers
the previous style, or has other suggestions just chime in and I'll
follow up.

llvm-svn: 128878