| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
friend function template, be sure to adjust the computed template
argument lists based on the location of the definition of the function
template: it's possible that the definition we're instantiating with
and the template declaration that we found when creating the
specialization are in different contexts, which meant that we would
end up using the wrong template arguments for instantiation.
Fixes PR7013; all Boost.DynamicBitset tests now pass.
llvm-svn: 102974
|
|
|
|
|
|
|
|
| |
treat argument types of objective-c pointer types
which only differ in their protocol qualifiers as
the same type (radar 7925668).
llvm-svn: 102955
|
|
|
|
|
|
|
|
| |
mapping from the declaration in the template to the instantiated
declaration before transforming the initializer, in case some crazy
lunatic decides to use a variable in its own initializer. Fixes PR7016.
llvm-svn: 102945
|
|
|
|
|
|
|
|
| |
(-Wunused-exception-parameter) than normal variables, since it's more
common to name and then ignore an exception parameter. This warning is
neither enabled by default nor by -Wall. Fixes <rdar://problem/7931045>.
llvm-svn: 102931
|
|
|
|
|
|
|
|
| |
(which is ill-formed) with an initializer list. Also, change the
fallback from an assertion to a generic error message, which is far
friendlier. Fixes <rdar://problem/7730948>.
llvm-svn: 102930
|
|
|
|
|
|
|
|
| |
conforms to a protocol as one of its super classes does. This is because
conforming super class will implement the property. This implements
new warning rules for unimplemented properties (radar 7884086).
llvm-svn: 102919
|
|
|
|
| |
llvm-svn: 102917
|
|
|
|
|
|
| |
of a base class, give it real source-location information. Fixes PR7017.
llvm-svn: 102916
|
|
|
|
|
|
| |
aren't in scope. Fixes PR7014.
llvm-svn: 102915
|
|
|
|
|
|
|
| |
to enter the instantiated parameter declarations into the local
instantiation scope; they can't be referenced anyway. Fixes PR7022.
llvm-svn: 102914
|
|
|
|
|
|
| |
as non-empty. Fixes PR7021.
llvm-svn: 102913
|
|
|
|
| |
llvm-svn: 102902
|
|
|
|
| |
llvm-svn: 102896
|
|
|
|
|
|
| |
expression constructs a non-virtual or virtual base.
llvm-svn: 102879
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
assignment operators.
Previously, Sema provided type-checking and template instantiation for
copy assignment operators, then CodeGen would synthesize the actual
body of the copy constructor. Unfortunately, the two were not in sync,
and CodeGen might pick a copy-assignment operator that is different
from what Sema chose, leading to strange failures, e.g., link-time
failures when CodeGen called a copy-assignment operator that was not
instantiation, run-time failures when copy-assignment operators were
overloaded for const/non-const references and the wrong one was
picked, and run-time failures when by-value copy-assignment operators
did not have their arguments properly copy-initialized.
This implementation synthesizes the implicitly-defined copy assignment
operator bodies in Sema, so that the resulting ASTs encode exactly
what CodeGen needs to do; there is no longer any special code in
CodeGen to synthesize copy-assignment operators. The synthesis of the
body is relatively simple, and we generate one of three different
kinds of copy statements for each base or member:
- For a class subobject, call the appropriate copy-assignment
operator, after overload resolution has determined what that is.
- For an array of scalar types or an array of class types that have
trivial copy assignment operators, construct a call to
__builtin_memcpy.
- For an array of class types with non-trivial copy assignment
operators, synthesize a (possibly nested!) for loop whose inner
statement calls the copy constructor.
- For a scalar type, use built-in assignment.
This patch fixes at least a few tests cases in Boost.Spirit that were
failing because CodeGen picked the wrong copy-assignment operator
(leading to link-time failures), and I suspect a number of undiagnosed
problems will also go away with this change.
Some of the diagnostics we had previously have gotten worse with this
change, since we're going through generic code for our
type-checking. I will improve this in a subsequent patch.
llvm-svn: 102853
|
|
|
|
|
|
| |
initialize the bases.
llvm-svn: 102842
|
|
|
|
|
|
|
|
|
|
|
| |
information required to implicitly define a C++ special member
function. Use it rather than explicitly setting CurContext on entry
and exit, which is fragile.
Use this RAII object for the implicitly-defined default constructor,
copy constructor, copy assignment operator, and destructor.
llvm-svn: 102840
|
|
|
|
|
|
|
| |
already knows what context it's looking in. Just pass that context in
instead of (questionably) recalculating it.
llvm-svn: 102818
|
|
|
|
|
|
| |
fatal error has occurred.
llvm-svn: 102778
|
|
|
|
|
|
|
|
|
| |
parameter with pointer-to-member type, we may have to perform a
qualification conversion, since the pointee type of the parameter
might be more qualified than the pointee type of the argument we form
from the declaration. Fixes PR6986.
llvm-svn: 102777
|
|
|
|
|
|
| |
constant expression in C.
llvm-svn: 102762
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of the mapping from local declarations to their instantiated
counterparts during template instantiation. Previously, we tried to do
some unholy merging of local instantiation scopes that involved
storing a single hash table along with an "undo" list on the
side... which was ugly, and never handled function parameters
properly.
Now, we just keep separate hash tables for each local instantiation
scope, and "combining" two scopes means that we'll look in each of the
combined hash tables. The combined scope stack is rarely deep, and
this makes it easy to avoid the "undo" issues we were hitting. Also,
I've simplified the logic for function parameters: if we're declaring
a function and we need the function parameters to live longer, we just
push them back into the local instantiation scope where we need them.
Fixes PR6990.
llvm-svn: 102732
|
|
|
|
|
|
| |
attributes invalid on type related checking so to add them to declarations only when everything is ok.
llvm-svn: 102710
|
|
|
|
|
|
| |
warning generation.
llvm-svn: 102705
|
|
|
|
|
|
|
|
|
|
|
| |
if *none* of the successors of the call expression is the exit block.
This matters when a call of bool type is the condition of (say) a while
loop in a function with no statements after the loop. This *can* happen
in C, but it's much more common in C++ because of overloaded operators.
Suppresses some substantial number of spurious -Wmissing-noreturn warnings.
llvm-svn: 102696
|
|
|
|
| |
llvm-svn: 102695
|
|
|
|
|
|
|
|
|
|
|
| |
specializations, which keeps track of the order in which they were
originally declared. We use this number so that we can always walk the
list of partial specializations in a predictable order during matching
or template instantiation. This also fixes a failure in Boost.Proto,
where SourceManager::isBeforeInTranslationUnit was behaving
poorly in inconsistent ways.
llvm-svn: 102693
|
|
|
|
|
|
|
|
|
| |
entering the current instantiation. Set up a little to preserve type location
information for typename types while we're in there.
Fixes a Boost failure.
llvm-svn: 102673
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
address of an overloaded function (or function template), perform that
resolution prior to determining the implicit conversion
sequence. This resolution is not part of the implicit conversion
sequence itself.
Previously, we would always consider this resolution to be a
function pointer decay, which was a lie: there might be an explicit &
in the expression, in which case decay should not occur. This caused
the CodeGen assertion in PR6973 (where we created a
pointer to a pointer to a function when we should have had a pointer
to a function), but it's likely that there are corner cases of
overload resolution where this would have failed.
Cleaned up the code involved in determining the type that will
produced afer resolving the overloaded function reference, and added
an assertion to make sure the result is correct. Fixes PR6973.
llvm-svn: 102650
|
|
|
|
|
|
|
| |
categories. Issue usual warnings instead of
confusing error message. Radar 7920807
llvm-svn: 102645
|
|
|
|
|
|
|
|
| |
ObjCMethodDecl::isVariadic().
Do some minor refactoring along the way.
llvm-svn: 102635
|
|
|
|
|
|
| |
for similar methods. No functionality change.
llvm-svn: 102634
|
|
|
|
|
|
|
|
|
| |
specializations, substitute the deduced template arguments and check
the resulting substitution before concluding that template argument
deduction succeeds. This marvelous little fix makes a bunch of
Boost.Spirit tests start working.
llvm-svn: 102601
|
|
|
|
|
|
|
| |
specializations, separate out the deduction part from the checking and
substitution of the deduced arguments.
llvm-svn: 102600
|
|
|
|
|
|
|
|
| |
bindings when the template argument is still an expression; it happens
while checking the template arguments of a class template partial
specializations. Fixes PR6964.
llvm-svn: 102595
|
|
|
|
|
|
| |
template decl itself, not its context. Testcase to follow; fixes selfhost.
llvm-svn: 102578
|
|
|
|
|
|
|
|
|
|
| |
template argument deduction or (more importantly) the final substitution
required by such deduction. Makes access control magically work in these
cases.
Fixes PR6967.
llvm-svn: 102572
|
|
|
|
|
|
|
|
| |
classes, since we only warn (not error) on offsetof() for non-POD
types. We store the base path within the OffsetOfExpr itself, then
evaluate the offsets within the constant evaluator.
llvm-svn: 102571
|
|
|
|
|
|
|
| |
as well as pre- and post-inc/decrements in C (not that I think it
matters for any C code).
llvm-svn: 102552
|
|
|
|
|
|
| |
members of anonymous structs/unions
llvm-svn: 102551
|
|
|
|
| |
llvm-svn: 102548
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Amadini.
This change introduces a new expression node type, OffsetOfExpr, that
describes __builtin_offsetof. Previously, __builtin_offsetof was
implemented using a unary operator whose subexpression involved
various synthesized array-subscript and member-reference expressions,
which was ugly and made it very hard to instantiate as a
template. OffsetOfExpr represents the AST more faithfully, with proper
type source information and a more compact representation.
OffsetOfExpr also has support for dependent __builtin_offsetof
expressions; it can be value-dependent, but will never be
type-dependent (like sizeof or alignof). This commit introduces
template instantiation for __builtin_offsetof as well.
There are two major caveats to this patch:
1) CodeGen cannot handle the case where __builtin_offsetof is not a
constant expression, so it produces an error. So, to avoid
regressing in C, we retain the old UnaryOperator-based
__builtin_offsetof implementation in C while using the shiny new
OffsetOfExpr implementation in C++. The old implementation can go
away once we have proper CodeGen support for this case, which we
expect won't cause much trouble in C++.
2) __builtin_offsetof doesn't work well with non-POD class types,
particularly when the designated field is found within a base
class. I will address this in a subsequent patch.
Fixes PR5880 and a bunch of assertions when building Boost.Python
tests.
llvm-svn: 102542
|
|
|
|
|
|
| |
ivar of c++ object types.
llvm-svn: 102500
|
|
|
|
|
|
| |
braces is none.
llvm-svn: 102496
|
|
|
|
|
|
|
|
|
| |
complete, return an error rather than falling back to building a
dependent declaration reference, since we might not be in a dependent
context. Fixes a fiendish crash-on-invalid in Boost.FunctionTypes that
I wasn't able to reduce to anything useful.
llvm-svn: 102491
|
|
|
|
|
|
|
|
| |
template argument deduction, use the lexical declaration context as
the owner for friend function templates. Fixes 2 failures in
Boost.Graph.
llvm-svn: 102489
|