| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RecursiveASTVisitor was not properly recursing through a
SubstTemplateTypeParmTypes, resulting in crashes in pack expansion where we
couldn't always find an unexpanded pack within a pack expansion.
We also have an issue where substitution of deduced template arguments for an
implicit deduction guide creates the "impossible" case of naming a
non-dependent member of the current instantiation, but within a specialization
that is actually instantiated from a different (partial/explicit)
specialization of the template. We resolve this by declaring that constructors
that do so can only be used to deduce specializations of the primary template.
I'm running this past CWG to see if people agree this is the right thing to do.
llvm-svn: 304862
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
member function" context notes to registering an entry on the context stack.
Also reorder the steps within defining special members to be consistent.
This has a few benefits: if multiple diagnostics are produced while checking
such a member, the note is now attached to the first such diagnostic rather
than the last, this prepares us for persisting these diagnostics between the
point at which we require the implicit instantiation of a template and the
point at which that instantiation is actually performed, and this fixes some
cases where we would fail to produce a full note stack leading back to user
code in the case of such a diagnostic.
The reordering exposed a case where we could recursively attempt to define a
defaulted destructor while we're already defining one (and other such cases
also appear to be possible, with or without this change), so this change also
reuses the "willHaveBody" flag on function declarations to track that we're in
the middle of synthesizing a body for the function and bails out if we try to
define a function that we're already defining.
llvm-svn: 303930
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Windows Itanium aims to use MSVC export and import semantics. Inner
class members shouldn't be exported on a dllexport explicit
instantiation definition of the outer class, and they shouldn't be
imported on a dllimport explicit instantiation declaration of the outer
class (instead a local copy should be emitted). We were doing the first
but not the second, and this mismatch can lead to link errors. Fix the
behavior and add tests for both.
Differential Revision: https://reviews.llvm.org/D32213
llvm-svn: 300804
|
|
|
|
|
|
|
|
| |
- also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17.
- update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed.
llvm-svn: 299316
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Correct class-template deprecation behavior
Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case:
template<typename T> [[deprecated]] class Foo{}; Foo<int> f;
This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute.
Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute.
Previous DiffRev: https://reviews.llvm.org/D27486, was reverted.
This patch fixes the issues brought up here by the reverter: https://reviews.llvm.org/rL298410
Differential Revision: https://reviews.llvm.org/D31245
llvm-svn: 298634
|
|
|
|
|
|
|
| |
This reverts commit r298410 (which produces incorrect warnings, see
comments on https://reviews.llvm.org/rL298410).
llvm-svn: 298504
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case:
template<typename T> [[deprecated]] class Foo{}; Foo<int> f;
This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute.
Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute.
Differential Revision: https://reviews.llvm.org/D27486
llvm-svn: 298410
|
|
|
|
|
|
| |
special member function.
llvm-svn: 296020
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the current one.
Rather than attempting to compare whether the previous and current top of
context stack are "equal" (which fails for a number of reasons, such as the
context stack entries containing pointers to objects on the stack, or reaching
the same "top of stack" entry through two different paths), track the depth of
context stack at which we last emitted a note and invalidate it when we pop the
context stack to less than that depth.
This causes us to emit some missing "in instantiation of" notes and to stop
emitting redundant "in instantiation of" stacks matching the previous stack in
rare cases.
llvm-svn: 295921
|
|
|
|
|
|
|
| |
using it for other kinds of context (where we currently produce context notes
in a highly ad-hoc manner).
llvm-svn: 295919
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template deduction guides for class template argument deduction.
Ensure that we have a local instantiation scope for tracking the instantiated
parameters. Additionally, unusually, we're substituting at depth 1 and leaving
depth 0 alone; make sure that we don't reduce template parameter depth by 2 for
inner parameters in the process. (This is probably also broken for alias
templates in the case where they're expanded within a dependent context, but
this patch doesn't fix that.)
llvm-svn: 295696
|
|
|
|
|
|
|
|
|
| |
typename-specifiers.
This reinstates r293455, reverted in r293455, with a fix for cv-qualifier
handling on dependent typename-specifiers.
llvm-svn: 293544
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Revert r293455, which breaks v8 with a spurious error. Testcase added.
Reviewers: klimek
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D29271
llvm-svn: 293473
|
|
|
|
|
|
| |
typename-specifiers.
llvm-svn: 293455
|
|
|
|
|
|
|
| |
Diagnose the case when a dependent template name instantiates to an
injected-class-name outside a nested-name-specifier.
llvm-svn: 292545
|
|
|
|
|
|
|
| |
Don't prematurely clean up an RAII object; there's another RAII object in the
same scope that tries to save and restore the same member!
llvm-svn: 291551
|
|
|
|
|
|
|
|
|
|
|
| |
deduction in partial ordering.
This prevents us from crashing due to attempting to instantiate the same class
template specialization definition multiple times. (Debug builds also appear to
sometimes hit the stack limit before hitting the instantiation depth limit in
this case.)
llvm-svn: 291407
|
|
|
|
|
|
|
|
| |
specialized than the primary template. (Put another way, if we imagine there
were a partial specialization matching the primary template, we should never
select it if some other partial specialization also matches.)
llvm-svn: 290593
|
|
|
|
| |
llvm-svn: 290485
|
|
|
|
|
|
| |
partial specialization arguments.
llvm-svn: 290484
|
|
|
|
|
|
|
| |
template arguments as written rather than the canonical template arguments,
so we print more user-friendly names for template parameters.
llvm-svn: 290483
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expressions in a function or class template.
This patch makes the following changes:
- Create a DependentScopeDeclRefExpr for the default argument instead of
a CXXDependentScopeMemberExpr.
- Pass CombineWithOuterScope=true so that the outer scope in which the
enum is declared is searched for the instantiation of the enum.
This is the first part of https://reviews.llvm.org/D23096. Fixes PR28795
rdar://problem/27535319
llvm-svn: 289914
|
|
|
|
|
|
|
| |
complete a little more general; it is produced in other cases than the one that
it previously talked about.
llvm-svn: 287713
|
|
|
|
| |
llvm-svn: 285938
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and FatalErrorOccurred are both set.
This fixes a crash that occurs when a warning promoted to a fatal error
leaves the AST in an incomplete state, and then later CFG analysis is
run on the incomplete AST.
rdar://problem/28558923
Differential Revision: https://reviews.llvm.org/D26166
llvm-svn: 285923
|
|
|
|
|
|
|
|
| |
C++1z.
Patch by James Touton! Some bugfixes and rebasing by me.
llvm-svn: 282651
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
within the instantiation of that same specialization. This could previously
happen for eagerly-instantiated function templates, variable templates,
exception specifications, default arguments, and a handful of other cases.
We still have an issue here for default template arguments that recursively
make use of themselves and likewise for substitution into the type of a
non-type template parameter, but in those cases we're producing a different
entity each time, so they should instead be caught by the instantiation depth
limit. However, currently we will typically run out of stack before we reach
it. :(
llvm-svn: 280190
|
|
|
|
|
|
| |
initializer of an imported field.
llvm-svn: 279667
|
|
|
|
|
|
| |
Reviewed by Richard Smith.
llvm-svn: 279164
|
|
|
|
|
|
| |
This is useful for source modification tools. There will be a follow-up commit using it.
llvm-svn: 275590
|
|
|
|
|
|
|
|
|
| |
ArrayRef is a little better than passing around a pointer/length
pair.
No functional change is intended.
llvm-svn: 274732
|
|
|
|
|
|
|
| |
variable weak discardable linkage and partially-ordered initialization, and is
implied for constexpr static data members.)
llvm-svn: 273754
|
|
|
|
|
|
| |
No functional change is intended, just a small refactoring.
llvm-svn: 273647
|
|
|
|
|
|
|
|
|
|
|
| |
It is possible for a field and a class to have the same name. In such
cases, performing lookup for the field might return a result set with
more than one entry. An overzealous assertion fired, causing us to
crash instead of using the non-class lookup result.
This fixes PR28060.
llvm-svn: 272247
|
|
|
|
|
|
|
|
| |
pretty stack trace entries for all cases where we instantiate the definition of
something, and include the fully-qualified name with template arguments in the
name of the instantiated entity.
llvm-svn: 270904
|
|
|
|
|
|
|
|
|
|
| |
definitions as declarations (PR27810, PR27811)"
Also make explicit instantiation decls not apply to nested classes when
targeting MSVC. That dll attributes are not inherited by inner classes
might be the explanation for MSVC's behaviour here.
llvm-svn: 270897
|
|
|
|
|
|
|
|
|
| |
This is in preparation for C++ P0136R1, which switches the model for inheriting
constructors over from synthesizing a constructor to finding base class
constructors (via using shadow decls) when looking for derived class
constructors.
llvm-svn: 269231
|
|
|
|
|
|
|
|
| |
declared before it is used. Because we don't use normal name lookup to find
these, the normal code to filter out non-visible names from name lookup results
does not apply.
llvm-svn: 268585
|
|
|
|
|
|
|
|
| |
lambda-expression. We don't actually instantiate the closure type / operator()
in the template in order to produce the closure type / operator() in the
instantiation, so this isn't caught by the normal path.
llvm-svn: 264184
|
|
|
|
| |
llvm-svn: 262289
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Relands r260194 with a fix. If we have a template that transitions from
an extern template to an explicitly instantiated dllexport template, we
would add that class to the delayed exported class list without flushing
it.
For explicit instantiations, we can just flush the list of delayed
classes immediately. We don't have to worry about the bug fixed in
r260194 in this case because explicit instantiations can only occur at
file and namespace scope.
Fixes PR26490.
llvm-svn: 262056
|
|
|
|
|
|
|
|
|
|
| |
instantiation"
This reverts commit r260194.
It caused PR26549. There's probably a better way to do this also.
llvm-svn: 260241
|
|
|
|
|
|
| |
Fixes PR26490
llvm-svn: 260194
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RecursiveASTVisitor::TraverseFunctionHelper() traverses a function's
ParmVarDecls by going to the function's getTypeSourceInfo if it exists, and
`DEF_TRAVERSE_TYPELOC(FunctionProtoType` then goes to the function's
ParmVarDecls.
For a function template that doesn't have parameters that explicitly depend on
the template parameter, we used to be clever and not build a new
TypeSourceInfo. That meant that when an instantiation of such a template is
visited, its TypeSourceInfo would point to the ParmVarDecls of the template,
not of the instantiation, which then confused clients of RecursiveASTVisitor.
So don't be clever for function templates that have parameters, even if none of
the parameters depend on the type.
Fixes PR26257.
http://reviews.llvm.org/D16478
llvm-svn: 259428
|
|
|
|
| |
llvm-svn: 256478
|
|
|
|
|
|
| |
It broke lldb build.
llvm-svn: 256403
|
|
|
|
| |
llvm-svn: 256401
|
|
|
|
| |
llvm-svn: 256399
|
|
|
|
|
|
|
|
| |
when eagerly instantiating them.
rdar://23721638
llvm-svn: 255325
|
|
|
|
|
|
|
|
|
| |
that change turns out to not be reasonable: mutating the AST of a parsed
template during instantiation is not a sound thing to do, does not work across
chained PCH / modules builds, and is in any case a special-case workaround to a
more general problem that should be solved centrally.
llvm-svn: 249342
|