| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
another.
llvm-svn: 103630
|
| |
|
|
|
|
|
| |
potentially-evaluated expression context, to ensure that used
declarations get properly marked. Fixes PR7123.
llvm-svn: 103624
|
| |
|
|
|
|
|
|
| |
member function (default constructor, copy constructor, copy
assignment operator, destructor), emit a note showing where that
implicit definition was required.
llvm-svn: 103619
|
| |
|
|
|
|
| |
a convenience routine to find the innermost common ancestor of two scopes.
llvm-svn: 103565
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
about the permitted scopes. Specifically:
1) Permit labels and gotos to appear after a prologue of variable initializations.
2) Permit indirect gotos to jump out of scopes that don't require cleanup.
3) Diagnose possible attempts to indirect-jump out of scopes that do require
cleanup.
This requires a substantial reinvention of the algorithm for checking indirect
goto. The current algorithm is Omega(M*N), with M = the number of unique
scopes being jumped from and N = the number of unique scopes being jumped to,
with an additional factor that is probably (worst-case) linear in the depth
of scopes. Thus the entire thing is likely cubic given some truly bizarre
ill-formed code; on well-formed code the additional factor collapses to
an amortized constant (when amortized over the entire function) and so
the algorithm is quadratic. Even this requires every label to appear in
its own scope, which would be very unusual for indirect-goto code (and
extremely unlikely for well-formed code); it is far more likely that
all labels will be in the same scope and so the algorithm becomes linear.
For such a marginal feature, I am fairly happy with this result.
(this is using JumpDiagnostic's definition of scope, where successive
variables in a block appear in their own scope)
llvm-svn: 103536
|
| |
|
|
|
|
| |
This is meaningful for blocks. This patch fixes bunch of test failures in gdb testsuite.
llvm-svn: 103533
|
| |
|
|
| |
llvm-svn: 103517
|
| |
|
|
|
|
| |
implicitly-instantiated class as ...", which seems to have broken bootstrap.
llvm-svn: 103515
|
| |
|
|
|
|
| |
- Fixes PR7098.
llvm-svn: 103514
|
| |
|
|
|
|
|
|
| |
referenced unless we see one of them defined (or the key function
defined, if it as one) or if we need the vtable for something. Fixes
PR7114.
llvm-svn: 103497
|
| |
|
|
| |
llvm-svn: 103494
|
| |
|
|
| |
llvm-svn: 103484
|
| |
|
|
|
|
|
|
|
|
| |
explicit instantiations of template. C++0x clarifies the intent
(they're ill-formed in some cases; see [temp.explicit] for
details). However, one could squint at the C++98/03 standard and
conclude they are permitted, so reduce the error to a warning
(controlled by -Wc++0x-compat) in C++98/03 mode.
llvm-svn: 103482
|
| |
|
|
|
|
|
|
| |
value-dependent if their initializers are value-dependent; my recent
tweak to these dependent rules overstepped by taking away this
value-dependents. Fixes a Boost.GIL regression.
llvm-svn: 103476
|
| |
|
|
| |
llvm-svn: 103475
|
| |
|
|
| |
llvm-svn: 103465
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
of the current instantiation is value-dependent. The C++ standard
fails to enumerate this case and, therefore, we missed it. Chandler
did all of the hard work of reducing the last remaining
Boost.PtrContainer failure (which had to do with static initialization
in the Serialization library) down to this simple little test.
While I'm at it, clean up the dependence rules for template arguments
that are declarations, and implement the dependence rules for template
argument packs.
llvm-svn: 103464
|
| |
|
|
| |
llvm-svn: 103458
|
| |
|
|
| |
llvm-svn: 103448
|
| |
|
|
|
|
| |
Fixes radar 7952457.
llvm-svn: 103447
|
| |
|
|
|
|
|
|
|
| |
of constant-evaluation. Formerly you could control whether it accepted
local l-values or not; now it always evaluates local l-values in the core
routines, but filters them out where consumed by the top-level routines.
This will make it much easier to cache evaluability.
llvm-svn: 103444
|
| |
|
|
|
|
|
| |
reference dot-syntax notation in a varierty of cases.
Fixes radar 7964490.
llvm-svn: 103440
|
| |
|
|
|
|
|
|
| |
only things that
aren't allocated this way are the internal FoldingSets.
llvm-svn: 103429
|
| |
|
|
|
|
|
|
|
|
| |
ASTContext's allocator.
While DeclarationNameTable doesn't leak, it uses 'malloc' too often. Start with having
'CXXLiteralOperatorNames' allocated using ASTContext's allocator and add a 'DoDestroy()' method
to DeclarationNameTable that is called by ~ASTContext.
llvm-svn: 103426
|
| |
|
|
|
|
| |
ASTContext's allocator. Fixes <rdar://problem/7961605>.
llvm-svn: 103421
|
| |
|
|
| |
llvm-svn: 103412
|
| |
|
|
|
|
| |
This fixes radar 7959934.
llvm-svn: 103408
|
| |
|
|
| |
llvm-svn: 103406
|
| |
|
|
| |
llvm-svn: 103403
|
| |
|
|
| |
llvm-svn: 103402
|
| |
|
|
| |
llvm-svn: 103390
|
| |
|
|
| |
llvm-svn: 103388
|
| |
|
|
|
|
| |
CXXExprWithTemporaries.
llvm-svn: 103387
|
| |
|
|
| |
llvm-svn: 103376
|
| |
|
|
| |
llvm-svn: 103375
|
| |
|
|
| |
llvm-svn: 103374
|
| |
|
|
|
|
|
| |
and deserialize as a CallExpr which is close, but ends up
deserializing with the wrong stmt class.
llvm-svn: 103371
|
| |
|
|
| |
llvm-svn: 103370
|
| |
|
|
|
|
| |
substitute explicit template arguments into a function template
llvm-svn: 103369
|
| |
|
|
| |
llvm-svn: 103368
|
| |
|
|
|
|
|
| |
non-existent condition expressions to boolean values during template
instantiation.
llvm-svn: 103364
|
| |
|
|
| |
llvm-svn: 103363
|
| |
|
|
|
|
|
|
|
| |
particular, don't complain about unused variables that have dependent
type until instantiation time, so that we can look at the type of the
variable. Moreover, only complain about unused variables that have
neither a user-declared constructor nor a non-trivial destructor.
llvm-svn: 103362
|
| |
|
|
|
|
| |
unused, since the operation has side effects.
llvm-svn: 103360
|
| |
|
|
|
|
| |
this will hold the largest empty subobject or 0 if the class doesn't have any empty subobjects.
llvm-svn: 103359
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
for, and switch), be careful to construct the full expressions as soon
as we perform template instantation, so we don't either forget to call
temporary destructors or destroy temporaries at the wrong time. This
is the template-instantiation analogue to r103187, during which I
hadn't realized that the issue would affect the handling of these
constructs differently inside and outside of templates.
Fixes a regression in Boost.Function.
llvm-svn: 103357
|
| |
|
|
| |
llvm-svn: 103355
|
| |
|
|
|
|
| |
in the generated bitcode.
llvm-svn: 103353
|
| |
|
|
|
|
| |
it's ASTContext-allocated now
llvm-svn: 103350
|
| |
|
|
|
|
| |
templates and conversion function templates.
llvm-svn: 103349
|