| Commit message (Collapse) | Author | Age | Files | Lines | 
| | 
| 
| 
| 
| 
| 
|  | 
VCallAndVBaseOffsetBuilder::getCurrentOffsetOffset() to CharUnits. No change
in functionality intended.
llvm-svn: 128603
 | 
| | 
| 
| 
| 
| 
| 
|  | 
VCallAndVBaseOffsetBuilder::AddVBaseOffsets() to CharUnits. No change in
functionality intended.
llvm-svn: 128600
 | 
| | 
| 
| 
| 
| 
|  | 
- Please never ever ever ever write a tool that sniffs this.
llvm-svn: 128599
 | 
| | 
| 
| 
| 
| 
|  | 
constructor to CharUnits. No change in functionality intended.
llvm-svn: 128598
 | 
| | 
| 
| 
| 
| 
| 
|  | 
VCallAndVBaseOffsetBuilder::AddVCallAndVBaseOffsets() to
CharUnits. No change in functionality intended.
llvm-svn: 128596
 | 
| | 
| 
| 
| 
| 
|  | 
into the Clang version.
llvm-svn: 128595
 | 
| | 
| 
| 
|  | 
llvm-svn: 128590
 | 
| | 
| 
| 
| 
| 
|  | 
<rdar://problem/9210154>.
llvm-svn: 128578
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
logic was divorced
from how we process ordinary function calls, had a tremendous about of redundancy, and relied
strictly on inlining behavior (which was incomplete) to provide semantics instead of falling
back to the conservative analysis we use for C functions.  This is a significant step into
making C++ analyzer support more useful.
llvm-svn: 128557
 | 
| | 
| 
| 
| 
| 
|  | 
Add a test case for synthesize ivar. // rdar://9070460
llvm-svn: 128554
 | 
| | 
| 
| 
| 
| 
|  | 
for prperty reference types. // rdar://9208606.
llvm-svn: 128551
 | 
| | 
| 
| 
| 
| 
|  | 
PHINode::Create() giving the (known or expected) number of operands.
llvm-svn: 128538
 | 
| | 
| 
| 
|  | 
llvm-svn: 128534
 | 
| | 
| 
| 
| 
| 
| 
|  | 
VCallAndVBaseOffsetBuilder::AddVCallOffsets() to CharUnits. No change in
functionality intended.
llvm-svn: 128531
 | 
| | 
| 
| 
| 
| 
|  | 
functionality intended.
llvm-svn: 128522
 | 
| | 
| 
| 
| 
| 
|  | 
intended.
llvm-svn: 128521
 | 
| | 
| 
| 
| 
| 
|  | 
to CharUnits. No change in functionality intended.
llvm-svn: 128520
 | 
| | 
| 
| 
| 
| 
|  | 
CharUnits. No change in functionality intended.
llvm-svn: 128516
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
number information for better user experience.
Restrict the fix. This fixes break.exp failures from gdb testsuite.
llvm-svn: 128513
 | 
| | 
| 
| 
|  | 
llvm-svn: 128512
 | 
| | 
| 
| 
| 
| 
|  | 
packages, and which packages/checkers are hidden.
llvm-svn: 128511
 | 
| | 
| 
| 
| 
| 
|  | 
commit r128474.
llvm-svn: 128475
 | 
| | 
| 
| 
| 
| 
|  | 
assert-less codepath marginally more efficient.
llvm-svn: 128472
 | 
| | 
| 
| 
| 
| 
|  | 
want to stop at closing '}'.
llvm-svn: 128471
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Microsoft mode.
This fixes a bunch of errors when compiling MSVC header files with the -DDLL flag.
llvm-svn: 128457
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
when the resolution took place due to a single template specialization
being named with an explicit template argument list. In this case, the
"resolution" doesn't take into account the target type at all, and
therefore can take place for functions, static member functions, and
*non-static* member functions. The latter weren't being properly checked
and their proper form enforced in this scenario. We now do so.
The result of this last form slipping through was some confusing logic
in IsStandardConversion handling of these resolved address-of
expressions which eventually exploded in an assert. Simplify this logic
a bit and add some more aggressive asserts to catch improperly formed
expressions getting into this routine.
Finally add systematic testing of member functions, both static and
non-static, in the various forms they can take. One of these is
essentially PR9563, and this commit fixes the crash in that PR. However,
the diagnostics for this are still pretty terrible. We at least are now
accepting the correct constructs and rejecting the invalid ones rather
than accepting invalid or crashing as before.
llvm-svn: 128456
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
to an assertion failure in the uninitialized variables analysis.  The problem is that Sema isn't properly registering a variable in a DeclContext (which -Wuninitialized relies on), but
my expertise on the template instantiation logic isn't good enough to fix this problem for real.  This patch worksaround the
problem in -Wuninitialized, but we should fix it for real later.
llvm-svn: 128443
 | 
| | 
| 
| 
| 
| 
|  | 
type-dependent expressions. Fixes rdar://9027658.
llvm-svn: 128437
 | 
| | 
| 
| 
| 
| 
| 
|  | 
an executable test to llvm test suite.
// rdar://9070460.
llvm-svn: 128435
 | 
| | 
| 
| 
|  | 
llvm-svn: 128433
 | 
| | 
| 
| 
|  | 
llvm-svn: 128427
 | 
| | 
| 
| 
| 
| 
|  | 
// rdar://9181463
llvm-svn: 128410
 | 
| | 
| 
| 
|  | 
llvm-svn: 128401
 | 
| | 
| 
| 
| 
| 
|  | 
functionality changed.
llvm-svn: 128396
 | 
| | 
| 
| 
| 
| 
|  | 
No change in functionality intended.
llvm-svn: 128393
 | 
| | 
| 
| 
| 
| 
|  | 
functionality intended.
llvm-svn: 128392
 | 
| | 
| 
| 
| 
| 
|  | 
functionality intended.
llvm-svn: 128391
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
required modifying a few tests that specifically use note include stacks
to check the source manager's view of include stacks. I've simply added
the flag to these tests for now, they may have to be more substantially
changed if we decide to remove support for note include stacks
altogether.
Also, add a test for include stacks on notes that was supposed to go in
with the previous commit.
llvm-svn: 128390
 | 
| | 
| 
| 
| 
| 
|  | 
an objc method. Fixes // rdar://9181463
llvm-svn: 128389
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
without the "template" keyword.
For example:
   typename C1<T>:: /*template*/ Iterator<0> pos; 
Also the error is downgraded to an ExtWarn in Microsoft mode.
llvm-svn: 128387
 | 
| | 
| 
| 
| 
| 
|  | 
CharUnits).
llvm-svn: 128386
 | 
| | 
| 
| 
| 
| 
|  | 
functionality intended.
llvm-svn: 128385
 | 
| | 
| 
| 
| 
| 
|  | 
CharUnits. No change in functionality intended.
llvm-svn: 128384
 | 
| | 
| 
| 
| 
| 
|  | 
functionality intended.
llvm-svn: 128383
 | 
| | 
| 
| 
| 
| 
|  | 
AltiVec vector types. It fixes bug 9347.
llvm-svn: 128381
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This is basically the same idea as the warning on uninitialized uses of
fields within an initializer list. As such, it is on by default and
under -Wuninitialized.
Original patch by Richard Trieu, with some massaging from me on the
wording and grouping of the diagnostics.
llvm-svn: 128376
 | 
| | 
| 
| 
| 
| 
|  | 
PIM section 2.5.1 - after initialization all elements have the value specified by the literal
llvm-svn: 128375
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Emit them instead with the linkage of the VTT.
I'm actually really ambivalent about this;  it's what GCC does, but outside
of improving code size (if the linkage is coalescing), I'm not sure it's
at all relevant.  Construction vtables are naturally referenced only by the
VTT, which is itself only referenced by complete-object constructors and
destructors;  giving the construction vtables possibly-external linkage is
important if you have an optimization that drills through the VTT to a
reference to a particular construction vtable which it cannot just emit
itself.
llvm-svn: 128374
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
These stacks are often less important than those on primary diagnostics.
As the number of notes grows, this becomes increasingly important. The
include stack printing is clever and doesn't print stacks for adjacent
diagnostics from the same file, but when a note is in between a sequence
of errors in a header file, and the notes all refer to some other file,
we end up getting a worst-case ping-pong of include stacks that take up
a great deal of vertical space.
Still, for now, the default behavior isn't changed. We can evaluate user
feedback with the flag.
Patch by Richard Trieu, a couple of style tweaks from me.
llvm-svn: 128371
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
default for -fwrapv if that flag isn't specified explicitly. We always
prefer an explict setting of -fwrapv when present. Also adds support for
-fno-wrapv to allow disabling -fwrapv even when -fno-strict-overflow is
passed.
llvm-svn: 128353
 |