| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
statements. This is the last of the Objective-C statements.
llvm-svn: 102356
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we will print with each error that occurs during template
instantiation. When the backtrace is longer than that, we will print
N/2 of the innermost backtrace entries and N/2 of the outermost
backtrace entries, then skip the middle entries with a note such as:
note: suppressed 2 template instantiation contexts; use
-ftemplate-backtrace-limit=N to change the number of template
instantiation entries shown
This should eliminate some excessively long backtraces that aren't
providing any value.
llvm-svn: 101882
|
|
|
|
|
|
|
|
| |
function declaration, since it may end up being changed (e.g.,
"extern" can become "static" if a prior declaration was static). Patch
by Enea Zaffanella and Paolo Bolzoni.
llvm-svn: 101826
|
|
|
|
|
|
|
|
| |
instantiating class members as part of an explicit
instantiation. Addresses a compilation problem in
Boost.Serialization.
llvm-svn: 101725
|
|
|
|
|
|
|
|
| |
sure to introduce them into the current Scope (when we have one) in
addition to the DeclContext for the class, so that they can be found
by name lookup for inline members of the class. Fixes PR6570.
llvm-svn: 101047
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function's type is (strictly speaking) non-dependent. This ensures
that, e.g., default function arguments get instantiated properly.
And, since I couldn't resist, collapse the two implementations of
function-parameter instantiation into calls to a single, new function
(Sema::SubstParmVarDecl), since the two had nearly identical code (and
each had bugs the other didn't!). More importantly, factored out the
semantic analysis of a parameter declaration into
Sema::CheckParameter, which is called both by
Sema::ActOnParamDeclarator (when parameters are parsed) and when a
parameter is instantiated. Previously, we were missing some
Objective-C and address-space checks on instantiated function
parameters.
Fixes PR6733.
llvm-svn: 101029
|
|
|
|
|
|
|
|
|
|
|
|
| |
specializations when the explicit instantiation was... explicitly
written, i.e., not the product of an explicit instantiation of an
enclosing class. Fixes this spurious warning when Clang builds LLVM:
/Volumes/Data/dgregor/Projects/llvm/lib/CodeGen/MachineDominators.cpp:22:1:
warning: explicit instantiation of 'addRoot' that occurs after an
explicit specialization will be ignored (C++0x extension) [-pedantic]
llvm-svn: 100900
|
|
|
|
|
|
| |
type isn't dependent. Fixes rdar://problem/7838962.
llvm-svn: 100871
|
|
|
|
|
|
| |
the C-only "optimization".
llvm-svn: 100022
|
|
|
|
| |
llvm-svn: 100018
|
|
|
|
|
|
|
| |
term "fix-it" everywhere and even *I* get tired of long names
sometimes. No functionality change.
llvm-svn: 100008
|
|
|
|
|
|
|
|
|
|
| |
involving substitution of deduced template arguments into a class
template partial specialization or function template, or when
substituting explicitly-specific template arguments into a function
template. We now print the actual deduced argument bindings so the
user can see what got deduced.
llvm-svn: 99923
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
check deduced non-type template arguments and template template
arguments against the template parameters for which they were deduced,
performing conversions as appropriate so that deduced template
arguments get the same treatment as explicitly-specified template
arguments. This is the bulk of PR6723.
Also keep track of whether deduction of a non-type template argument
came from an array bound (vs. anywhere else). With this information,
we enforce C++ [temp.deduct.type]p17, which requires exact type
matches when deduction deduces a non-type template argument from
something that is not an array bound.
Finally, when in a SFINAE context, translate the "zero sized
arrays are an extension" extension diagnostic into a hard error (for
better standard conformance), which was a minor part of PR6723.
llvm-svn: 99734
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- When substituting template arguments as part of template argument
deduction, introduce a new local instantiation scope.
- When substituting into a function prototype type, introduce a new
"temporary" local instantiation scope that merges with its outer
scope but also keeps track of any additions it makes, removing
them when we exit that scope.
Fixes PR6700, where we were getting too much mixing of local
instantiation scopes due to template argument deduction that
substituted results into function types.
llvm-svn: 99509
|
|
|
|
|
|
| |
scope. Fixes PR6619.
llvm-svn: 99377
|
|
|
|
| |
llvm-svn: 98375
|
|
|
|
|
|
|
|
|
|
|
| |
instantiation. Based on a patch by Enea Zaffanella! I found a way to
reduce some of the redundancy between TreeTransform's "standard"
FunctionProtoType transformation and TemplateInstantiator's override,
and I killed off the old SubstFunctionType by adding type source info
for the last cases where we were creating FunctionDecls without TSI
(at least that get passed through template instantiation).
llvm-svn: 98252
|
|
|
|
|
|
| |
TransformDefinition.
llvm-svn: 97445
|
|
|
|
|
|
|
| |
given declaration in a template, make sure that the context we're
searching through is complete. Fixes PR6376.
llvm-svn: 97444
|
|
|
|
|
|
|
|
|
| |
class types, dependent types, and namespaces. I had previously
weakened this invariant while working on parsing pseudo-destructor
expressions, but recent work in that area has made these changes
unnecessary.
llvm-svn: 97112
|
|
|
|
|
|
|
|
|
|
|
|
| |
nested-name-specifier, e.g.,
typedef int Int;
int *p;
p->Int::~Int();
This weakens the invariant that the only types in nested-name-specifiers are tag types (restricted to class types in C++98/03). However, we weaken this invariant as little as possible, accepting arbitrary types in nested-name-specifiers only when we're in a member access expression that looks like a pseudo-destructor expression.
llvm-svn: 96743
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
now cope with the destruction of types named as dependent templates,
e.g.,
y->template Y<T>::~Y()
Nominally, we implement C++0x [basic.lookup.qual]p6. However, we don't
follow the letter of the standard here because that would fail to
parse
template<typename T, typename U>
X0<T, U>::~X0() { }
properly. The problem is captured in core issue 339, which gives some
(but not enough!) guidance. I expect to revisit this code when the
resolution of 339 is clear, and/or we start capturing better source
information for DeclarationNames.
Fixes PR6152.
llvm-svn: 96367
|
|
|
|
|
|
| |
methods.
llvm-svn: 96283
|
|
|
|
|
|
| |
complete function type of the member functions (using PredefinedExpr::ComputeName.
llvm-svn: 95887
|
|
|
|
|
|
|
| |
and CXXRecordDecl::getDefinition(); it's totally unnecessary. No
functionality change.
llvm-svn: 95836
|
|
|
|
|
|
|
|
| |
non-type template parameter that has reference type, augment the
qualifiers of the non-type template argument with those of the
referenced type. Fixes PR6250.
llvm-svn: 95607
|
|
|
|
|
|
|
| |
may be some other places that could take advantage of this new information,
but I haven't really looked yet.
llvm-svn: 95600
|
|
|
|
|
|
|
|
|
|
|
| |
params. Don't insert addrof operations when matching against a pointer;
array/function conversions should take care of this for us, assuming the
argument type-checked in the first place. Add a fixme where we seem to be
using a less-restrictive reference type than we should.
Fixes PR 6249.
llvm-svn: 95495
|
|
|
|
| |
llvm-svn: 95491
|
|
|
|
|
|
|
| |
non-type template argument for a non-type template parameter of
pointer type. Fixes PR6244.
llvm-svn: 95447
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when instantiating the declaration of a member template:
- Only check if the have a template template argument at a specific position
when we already know that we have template arguments at that level;
otherwise, we're substituting for a level-reduced template template
parameter.
- When trying to find an instantiated declaration for a template
template parameter, look into the instantiated scope. This was a
typo, where we had two checks for TemplateTypeParmDecl, one of
which should have been a TemplateTemplateParmDecl.
With these changes, tramp3d-v4 passes -fsyntax-only.
llvm-svn: 95421
|
|
|
|
|
|
|
| |
always come from the primary template, so gather the instantiation
template arguments from the primary template.
llvm-svn: 95380
|
|
|
|
|
|
|
|
|
| |
template parameter, perform array/function decay (if needed), take the
address of the argument (if needed), perform qualification conversions
(if needed), and remove any top-level cv-qualifiers from the resulting
expression. Fixes PR6226.
llvm-svn: 95309
|
|
|
|
|
|
|
| |
explicit '&' by introducing an address-of operator prior to checking the
argument's type.
llvm-svn: 94947
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
deterministic and work properly with templates. Once a class that
needs a vtable has been defined, we now do one if two things:
- If the class has no key function, we place the class on a list of
classes whose virtual functions will need to be "marked" at the
end of the translation unit. The delay until the end of the
translation unit is needed because we might see template
specializations of these virtual functions.
- If the class has a key function, we do nothing; when the key
function is defined, the class will be placed on the
aforementioned list.
At the end of the translation unit, we "mark" all of the virtual
functions of the classes on the list as used, possibly causing
template instantiation and other classes to be added to the
list. This gets LLVM's lib/Support/CommandLine.cpp compiling again.
llvm-svn: 92821
|
|
|
|
|
|
|
|
|
| |
expressions (e.g., for template instantiation), just transform the
subexpressions and return those, since the temporary-related nodes
will be implicitly regenerated. Fixes PR5867, but I said that
before...
llvm-svn: 92135
|
|
|
|
|
|
|
|
| |
the default argument so that we're sure to mark any referenced
declarations. This gets us another little step closer to fixing
PR5810.
llvm-svn: 92078
|
|
|
|
|
|
|
|
|
| |
horrible isAddressOfOperand hack in TreeTransform, since that syntactic
information is managed by the initial parser callbacks now.
That's enough insomniac commits for one night.
llvm-svn: 90849
|
|
|
|
|
|
| |
Template instantiation can re-use DeclRefExprs.
llvm-svn: 90848
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
variables,
but the results are imperfect.
For posterity, I did:
cat <<EOF > $cmdfile
s/DeclaratorInfo/TypeSourceInfo/g
s/DInfo/TInfo/g
s/TypeTypeSourceInfo/TypeSourceInfo/g
s/SourceTypeSourceInfo/TypeSourceInfo/g
EOF
find lib -name '*.cpp' -not -path 'lib/Parse/*' -exec sed -i '' -f $cmdfile '{}' \;
find lib -name '*.h' -exec sed -i '' -f $cmdfile '{}' \;
find include -name '*.h' -not -path 'include/clang/Parse/*' -not -path 'include/clang/Basic/*' -exec sed -i '' -f $cmdfile '{}' \;
llvm-svn: 90743
|
|
|
|
|
|
| |
subsequent code which depends on a complete type does the right thing.
llvm-svn: 90727
|
|
|
|
| |
llvm-svn: 90614
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instantiation, to ensure that we mark class template specilizations as
abstract when we need to and perform checking of abstract classes.
Also, move the checking that determines whether we are creating a
variable of abstract class type *after* we check whether the type is
complete. Otherwise, we won't see when we have an abstract class
template specialization that is implicitly instantiated by this
declaration. This is the "something else" that Sebastian had noted
earlier.
llvm-svn: 90467
|
|
|
|
|
|
| |
need to copy its attributes down to the instantiated class.
llvm-svn: 90463
|
|
|
|
| |
llvm-svn: 90044
|