| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 103517
|
| |
|
|
|
|
| |
implicitly-instantiated class as ...", which seems to have broken bootstrap.
llvm-svn: 103515
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Fixes radar 7952457.
llvm-svn: 103447
|
| |
|
|
|
|
| |
substitute explicit template arguments into a function template
llvm-svn: 103369
|
| |
|
|
|
|
|
| |
non-existent condition expressions to boolean values during template
instantiation.
llvm-svn: 103364
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
it's ASTContext-allocated now
llvm-svn: 103350
|
| |
|
|
|
|
| |
templates and conversion function templates.
llvm-svn: 103349
|
| |
|
|
|
|
|
|
|
|
|
| |
specific message that includes the template arguments, e.g.,
test/SemaTemplate/overload-candidates.cpp:27:20: note: candidate template
ignored: substitution failure [with T = int *]
typename T::type get_type(const T&); // expected-note{{candidate ...
^
llvm-svn: 103348
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
failed because the explicitly-specified template arguments did not
match its template parameters, e.g.,
test/SemaTemplate/overload-candidates.cpp:18:8: note: candidate
template
ignored: invalid explicitly-specified argument for template
parameter 'I'
void get(const T&);
^
test/SemaTemplate/overload-candidates.cpp:20:8: note: candidate
template
ignored: invalid explicitly-specified argument for 1st template
parameter
void get(const T&);
^
llvm-svn: 103344
|
| |
|
|
|
|
| |
this issue.
llvm-svn: 103343
|
| |
|
|
|
|
| |
functionality change.
llvm-svn: 103342
|
| |
|
|
|
|
|
| |
many/too few arguments, use the same diagnostic we use for arity
mismatches in non-templates (but note that it's a function template).
llvm-svn: 103341
|
| |
|
|
|
|
|
|
|
|
|
|
| |
conflicting deduced template argument values, give a more specific
reason along with those values, e.g.,
test/SemaTemplate/overload-candidates.cpp:4:10: note: candidate template
ignored: deduced conflicting types for parameter 'T' ('int' vs. 'long')
const T& min(const T&, const T&);
^
llvm-svn: 103339
|
| |
|
|
|
|
|
| |
mark any declarations we see inside of that type as
"referenced". Fixes PR7079.
llvm-svn: 103323
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ensure that we complete the type when we need to look at constructors
during reference binding.
When determining whether the two types involved in reference binding
are reference-compatible, reference-related, etc., do not complete the
type of the reference itself because it is not necessary to determine
well-formedness of the program. Complete the type that we are binding
to, since that can affect whether we know about a derived-to-base
conversion.
Re-fixes PR7080.
llvm-svn: 103283
|
| |
|
|
| |
llvm-svn: 103259
|
| |
|
|
| |
llvm-svn: 103250
|
| |
|
|
| |
llvm-svn: 103248
|
| |
|
|
| |
llvm-svn: 103247
|
| |
|
|
|
|
|
|
|
|
|
|
| |
are reference-compatible, reference-related, etc., do not complete the
type of the reference itself because it is not necessary to determine
well-formedness of the program. Complete the type that we are binding
to, since that can affect whether we know about a derived-to-base
conversion.
Fixes PR7080.
llvm-svn: 103220
|
| |
|
|
|
|
| |
casts, but still require the (casted) type to be a pointer. Fixes PR5685.
llvm-svn: 103216
|
| |
|
|
|
|
| |
scope. Thanks to Steven Watanabe for correcting me.
llvm-svn: 103210
|
| |
|
|
| |
llvm-svn: 103198
|
| |
|
|
|
|
| |
Fixes rdar://problem/4232969, or at least the clang parts of it.
llvm-svn: 103191
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
if/switch/while/do/for statements. Previously, we would end up either:
(1) Forgetting to destroy temporaries created in the condition (!),
(2) Destroying the temporaries created in the condition *before*
converting the condition to a boolean value (or, in the case of a
switch statement, to an integral or enumeral value), or
(3) In a for statement, destroying the condition's temporaries at
the end of the increment expression (!).
We now destroy temporaries in conditions at the right times. This
required some tweaking of the Parse/Sema interaction, since the parser
was building full expressions too early in many places.
Fixes PR7067.
llvm-svn: 103187
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
"bottom-up" when implicit casts and comparisons are inserted, compute them
"top-down" when the full expression is finished. Makes it easier to
coordinate warnings and thus implement -Wconversion for signedness
conversions without double-warning with -Wsign-compare. Also makes it possible
to realize that a signedness conversion is okay because the context is
performing the inverse conversion. Also simplifies some logic that was
trying to calculate the ultimate comparison/result type and getting it wrong.
Also fixes a problem with the C++ explicit casts which are often "implemented"
in the AST with a series of implicit cast expressions.
llvm-svn: 103174
|
| |
|
|
|
|
|
| |
an enum in the enum decl itself. Use some spare bits from TagDecl for this
purpose.
llvm-svn: 103173
|
| |
|
|
|
|
|
| |
float -> double (which happens because they are modelled as int(...)
functions), and add a testcase for isinf.
llvm-svn: 103167
|
| |
|
|
|
|
|
|
|
| |
different tag kind ("struct" vs. "class") than the primary template,
which has an affect on access control.
Should fix the last remaining Boost.Accumulors failure.
llvm-svn: 103144
|
| |
|
|
| |
llvm-svn: 103141
|
| |
|
|
|
|
|
|
|
| |
provide a note that shows where the copy-assignment operator was
needed. We used to have this, but I broke it during refactoring.
Finishes PR6999.
llvm-svn: 103127
|
| |
|
|
|
|
|
| |
of properties which are of C++ objects. Code Gen to follow
(Radar 7468090).
llvm-svn: 103123
|
| |
|
|
|
|
|
| |
with no whitespace. This will allow statements to be referred to in
attribute TableGen files.
llvm-svn: 103087
|
| |
|
|
|
|
|
| |
whitespace which makes this patch unreadable. Will recommit without the
whitespace.
llvm-svn: 103086
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ParseOptionalCXXScopeSpecifier() only annotates the subset of
template-ids which are not subject to lexical ambiguity. Add support
for the more general case in ParseUnqualifiedId() to handle cases
such as A::template B().
Also improve some diagnostic locations.
Fixes PR7030, from Alp Toker!
llvm-svn: 103081
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implicitly-generated copy constructor. Previously, Sema would perform
some checking and instantiation to determine which copy constructors,
etc., would be called, then CodeGen would attempt to figure out which
copy constructor to call... but would get it wrong, or poke at an
uninstantiated default argument, or fail in other ways.
The new scheme is similar to what we now do for the implicit
copy-assignment operator, where Sema performs all of the semantic
analysis and builds specific ASTs that look similar to the ASTs we'd
get from explicitly writing the copy constructor, so that CodeGen need
only do a direct translation.
However, it's not quite that simple because one cannot explicit write
elementwise copy-construction of an array. So, I've extended
CXXBaseOrMemberInitializer to contain a list of indexing variables
used to copy-construct the elements. For example, if we have:
struct A { A(const A&); };
struct B {
A array[2][3];
};
then we generate an implicit copy assignment operator for B that looks
something like this:
B::B(const B &other) : array[i0][i1](other.array[i0][i1]) { }
CodeGen will loop over the invented variables i0 and i1 to visit all
elements in the array, so that each element in the destination array
will be copy-constructed from the corresponding element in the source
array. Of course, if we're dealing with arrays of scalars or class
types with trivial copy-assignment operators, we just generate a
memcpy rather than a loop.
Fixes PR6928, PR5989, and PR6887. Boost.Regex now compiles and passes
all of its regression tests.
Conspicuously missing from this patch is handling for the exceptional
case, where we need to destruct those objects that we have
constructed. I'll address that case separately.
llvm-svn: 103079
|
| |
|
|
| |
llvm-svn: 103077
|
| |
|
|
| |
llvm-svn: 103072
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
typedef int functype(int, int);
functype func;
also instantiate the synthesized function parameters for the resulting
function declaration.
With this change, Boost.Wave builds and passes all of its regression
tests.
llvm-svn: 103025
|
| |
|
|
|
|
|
|
|
| |
implicitly-defined copy assignment operator, suppress the protected
access check. This eliminates the remaining failure in the
Boost.SmartPtr library (that was a product of the copy-assignment
generation rewrite) and, presumably, the Boost.TR1 library as well.
llvm-svn: 103010
|
| |
|
|
|
|
| |
class. Add some conservative support for the idea. Fixes PR 7024.
llvm-svn: 102999
|
| |
|
|
|
|
|
|
|
| |
not just the inner expression. This is important if the expression has any
temporaries. Fixes PR 7028.
Basically a symptom of really tragic method names.
llvm-svn: 102998
|