Other compilers accept invalid code here that we reject, and we need a
better error message to try to convince users that the code is really
incorrect. Consider:
class Foo {
typedef MyIterHelper<Foo> iterator;
friend class iterator;
};
Previously our wording was "elaborated type refers to a typedef".
"elaborated type" isn't widely known terminology, so the new diagnostic
says "typedef 'iterator' cannot be referenced with class specifier".
Reviewers: rsmith
Differential Revision: https://reviews.llvm.org/D25216
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289259 91177308-0d34-0410-b5e6-96231b3b80d8
Some functions and templates are treated as __host__ __device__ even
when they don't have explicitly specified target attributes.
What's worse, this treatment may change depending on command line
options (-fno-cuda-host-device-constexpr) or
#pragma clang force_cuda_host_device.
Combined with strict checking for matching function target that comes
with D25809(r288962), it makes it hard to write code which would
explicitly instantiate or specialize some functions regardless of
pragmas or command line options in effect.
This patch changes the way we match target attributes of base template
vs attributes used in explicit instantiation or specialization so that
only explicitly specified attributes are considered. This makes base
template selection behave consistently regardless of pragma of command
line options that may affect CUDA target.
Differential Revision: https://reviews.llvm.org/D25845
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289091 91177308-0d34-0410-b5e6-96231b3b80d8
* __host__ __device__ functions are no longer considered to be
redeclarations of __host__ or __device__ functions. This prevents
unintentional merging of target attributes across them.
* Function target attributes are not considered (and must match) during
explicit instantiation and specialization of function templates.
Differential Revision: https://reviews.llvm.org/D25809
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288962 91177308-0d34-0410-b5e6-96231b3b80d8
On MSVC, if an implicit instantiation already exists and an explicit
instantiation definition with a DLL attribute is created, the DLL
attribute still takes effect. Make clang match this behavior for
exporting.
Differential Revision: https://reviews.llvm.org/D26657
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288682 91177308-0d34-0410-b5e6-96231b3b80d8
An explicit template specialization can cause the implicit template
specialization of a type which inherits the attributes. In such a case, we
would end up with a delayed template specialization for a dll exported type
which we would fail to reference. This would trigger an assertion.
We now propagate the dll storage attributes through the inheritance
chain. Only after having done so do we reference the delayed template
specializations. This allows any implicit specializations which inherit dll
storage to also be referenced.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288570 91177308-0d34-0410-b5e6-96231b3b80d8
arguments from a declaration; despite what the standard says, this form of
deduction should not be considering exception specifications.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288301 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to r284288, make the Itanium ABI follow MS ABI dllexport
semantics in the case of an explicit instantiation declaration followed
by a dllexport explicit instantiation definition.
Differential Revision: https://reviews.llvm.org/D26471
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286419 91177308-0d34-0410-b5e6-96231b3b80d8
This commit improves the "must have C++ linkage" error diagnostics that are
emitted for C++ declarations like templates and literal operators by adding an
additional note that points to the appropriate extern "C" linkage specifier.
rdar://19021120
Differential Revision: https://reviews.llvm.org/D26189
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285823 91177308-0d34-0410-b5e6-96231b3b80d8
1) Merge and demote variable definitions when we find a redefinition in
MergeVarDecls, not only when we find one in AddInitializerToDecl (we only reach
the second case if it's the addition of the initializer itself that converts an
existing declaration into a definition).
2) When rebuilding a redeclaration chain for a variable, if we merge two
definitions together, mark the definitions as merged so the retained definition
is made visible whenever the demoted definition would have been.
Original commit message (from r283882):
[modules] PR28752: Do not instantiate variable declarations which are not visible.
Original patch by Vassil Vassilev! Changes listed above are mine.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284284 91177308-0d34-0410-b5e6-96231b3b80d8
export-declarations. These don't yet have an effect on name visibility;
we still export everything by default.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280999 91177308-0d34-0410-b5e6-96231b3b80d8
explicit specialization to a warning for C++98 mode (this is a defect report
resolution, so per our informal policy it should apply in C++98), and turn
the warning on by default for C++11 and later. In all cases where it fires, the
right thing to do is to remove the pointless explicit instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280308 91177308-0d34-0410-b5e6-96231b3b80d8
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. :(
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280190 91177308-0d34-0410-b5e6-96231b3b80d8
to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly
determine whether a function definition is visible, and mark both the function
and the template as visible when merging function template definitions to
provide hasVisibleDefinition with the relevant information.
The change to always pass the right declaration as the PatternDef to
DiagnoseUninstantiableTemplate also caused those checks to happen before other
diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the
same situations, so I sunk the relevant diagnostics into
DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes
in reviews.llvm.org/D23492 by Vassil Vassilev.
This reinstates r279486, reverted in r279500, with a fix to
DiagnoseUninstantiableTemplate to only mark uninstantiable explicit
instantiation declarations as invalid if we actually diagnosed them. (When we
trigger an explicit instantiation of a class member from an explicit
instantiation declaration for the class, it's OK if there is no corresponding
definition and we certainly don't want to mark the member invalid in that
case.) This previously caused a build failure during bootstrap.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279557 91177308-0d34-0410-b5e6-96231b3b80d8
to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly
determine whether a function definition is visible, and mark both the function
and the template as visible when merging function template definitions to
provide hasVisibleDefinition with the relevant information.
The change to always pass the right declaration as the PatternDef to
DiagnoseUninstantiableTemplate also caused those checks to happen before other
diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the
same situations, so I sunk the relevant diagnostics into
DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes
in reviews.llvm.org/D23492 by Vassil Vassilev.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279486 91177308-0d34-0410-b5e6-96231b3b80d8
decomposition declaration for arrays, aggregate-like structs, tuple-like
types, and (as an extension) for complex and vector types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278435 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Space for storing the //constraint-expression// of the
//requires-clause// associated with a `TemplateParameterList` is
arranged by taking a bit out of the `NumParams` field for the purpose
of determining whether there is a //requires-clause// or not, and by
adding to the trailing objects tied to the `TemplateParameterList`. An
accessor is provided.
An appropriate argument is supplied to `TemplateParameterList::Create`
at the various call sites.
Serialization changes will addressed as the Concepts implementation
becomes more solid.
Drive-by fix:
This change also replaces the custom
`FixedSizeTemplateParameterListStorage` implementation with one that
follows the interface provided by `llvm::TrailingObjects`.
Reviewers: aaron.ballman, faisalv, rsmith
Subscribers: cfe-commits, nwilson
Differential Revision: https://reviews.llvm.org/D19322
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276069 91177308-0d34-0410-b5e6-96231b3b80d8
After thinking about it, we don't really need to forbid
BuiltinTemplateDecls explicitly. The restriction doesn't really buy us
anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275078 91177308-0d34-0410-b5e6-96231b3b80d8
We hit over stringent asserts when trying to diagnose. Loosen them as
appropriate.
This fixes PR28494.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275047 91177308-0d34-0410-b5e6-96231b3b80d8
ArrayRef is a little better than passing around a pointer/length
pair.
No functional change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274732 91177308-0d34-0410-b5e6-96231b3b80d8
ArrayRef is a little better than passing around a pointer/length pair.
No functional change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274475 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a __nth_element builtin that allows fetching the n-th type of a
parameter pack with very little compile-time overhead. The patch was inspired by
r252036 and r252115 by David Majnemer, which add a similar __make_integer_seq
builtin for efficiently creating a std::integer_sequence.
Reviewed as D15421. http://reviews.llvm.org/D15421
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274316 91177308-0d34-0410-b5e6-96231b3b80d8
See https://llvm.org/bugs/show_bug.cgi?id=28100.
In r266561 when I implemented allowing explicit specializations of function templates to override deleted status, I mistakenly assumed (and hence introduced a violable assertion) that when an explicit specialization was being declared, the corresponding specialization of the most specialized function template that it would get linked to would always be the one that was implicitly generated - and so if it was marked as 'deleted' it must have inherited it from the primary template and so should be safe to reset its deleted status, and set it to being an explicit specialization. Obviously during redeclaration of a deleted explicit specialization, in order to avoid a recursive reset, we need to check that the previous specialization is not an explicit specialization (instead of assuming and asserting it) and that it hasn't been referenced, and so only then is it safe to reset its 'deleted' status.
All regression tests pass.
Thanks to Zhendong Su for reporting the bug and David Majnemer for tracking it to my commit r266561, and promptly bringing it to my attention.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272631 91177308-0d34-0410-b5e6-96231b3b80d8
Crash reported in PR28023 is caused by the fact that non-type template
parameters are found by tag name lookup. In the code provided in that PR:
template<int V> struct A {
struct B {
template <int> friend struct V;
};
};
the template parameter V is found when lookup for redeclarations of 'struct V'
is made. Latter on the error about shadowing of 'V' is emitted but the semantic
context of 'struct V' is already determined wrong: 'struct A' instead of
translation unit.
The fix moves the check for shadowing toward the beginning of the method and
thus prevents from wrong context calculations.
This change fixes PR28023.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272366 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@270897 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269231 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@268585 91177308-0d34-0410-b5e6-96231b3b80d8
template<class T> void f(T) = delete;
template<> void f(int); // OK.
f(3); // OK
Implementation strategy:
When an explicit specialization of a function template, a member function template or a member function of a class template is declared, clang first implicitly instantiates the declaration of a specialization from the templated-entity being explicitly specialized (since their signatures must be the same) and then links the explicit specialization being declared as a redeclaration of the aforementioned specialization.
The problem was that when clang 'implicitly instantiates' the initial specialization, it marks the corresponding FunctionDecl as deleted if the corresponding templated-entity was deleted, rather than waiting to see whether the explicit specialization being declared provides a non-deleted body. (The eager marking of delete has advantages during overload resolution I suppose, where we don't have to try and instantiate a definition of the function to see if it is deleted).
The present fix entails recognizing that when clang knows that an explicit specialization is being declared (for whichever templated-entity), the prior implicit instantiation should not inherit the 'deleted' status, and so we reset it to false.
I suppose an alternative fix (amongst others) could consider creating a new context (ExplicitSpecializationDeclarationSubstitution or some such) that is checked during template-argument-deduction and final substitution, and avoid inheriting the deleted status during declaration substitution. But while conceptually cleaner, that would be a slightly more involved change (as could be some of the other alternatives: such as avoid tagging implicit specializations as deleted, and check their primary templates for the deleted status where needed), and so I chose a different path. Hopefully it'll prove to not be a bad choice.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266561 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: A program shall not declare an explicit instantiation (14.8.2), an explicit specialization (14.8.3), or a partial specialization of a concept definition.
Reviewers: rsmith, hubert.reinterpretcast, faisalv, aaron.ballman
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18221
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265868 91177308-0d34-0410-b5e6-96231b3b80d8
The prior diagnostic (err_template_arg_not_class_template) would state that the template argument to a template template parameter can only be a class template, when it can also be a template alias. The newly renamed diagnostic (err_template_arg_not_valid_template) mentions template aliases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264522 91177308-0d34-0410-b5e6-96231b3b80d8
This feature works outside of templates by forming a DeclRefExpr to a
FieldDecl instead of a MemberExpr, which requires a base object in
addition to the FieldDecl.
Previously, while building up the template AST before instantiation, we
formed a CXXDependentScopeMemberExpr, which always instantiates to a
MemberExpr. Now, in unevaluated contexts we form a
DependentScopeDeclRefExpr, which is a more flexible node that can
instantiate to either a MemberExpr or a DeclRefExpr depending on lookup
results.
Fixes PR26893.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263279 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262056 91177308-0d34-0410-b5e6-96231b3b80d8
diagnosing when 'concept' is specified on a function or template
specialization.
Since a concept can only be applied to a function or variable template,
the concept bit is stored in TemplateDecl as a PointerIntPair.
Reviewers: rsmith, faisalv, aaron.ballman, hubert.reinterpretcast
Differential Revision: http://reviews.llvm.org/D13357
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260074 91177308-0d34-0410-b5e6-96231b3b80d8
Or, do not set Sema's CurContext to the template declaration's when substituting into default template arguments of said template declaration.
If we do push the template declaration context on to Sema, and the template declaration is at namespace scope, Sema can get confused and try and do odr analysis when substituting into default template arguments, even though the substitution could be occurring within a dependent context.
I'm not sure why this was being done, perhaps there was concern that if a default template argument referred to a previous template parameter, it might not be found during substitution - but all regression tests pass, and I can't craft a test that would cause it to fails (if some one does, please inform me, and i'll craft a different fix for the PR).
This patch removes a single line of code, but unfortunately adds more than it removes, because of the tests. Some day I still hope to commit a patch that removes far more lines than it adds, while leaving clang better for it ;)
Sorry that r253590 ("Change the expression evaluation context from Unevaluated to ConstantEvaluated while substituting into non-type template argument defaults") caused the PR!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258110 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Support for OpenCL 2.0 pipe type.
This is a bug-fix version for bader's patch reviews.llvm.org/D14441
Reviewers: pekka.jaaskelainen, Anastasia
Subscribers: bader, Anastasia, cfe-commits
Differential Revision: http://reviews.llvm.org/D15603
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257254 91177308-0d34-0410-b5e6-96231b3b80d8
underlying decls. Preserve the found declaration throughout, and only map to
the underlying declaration when we want to check whether it's the right kind.
This allows us to provide the right source location for the found declaration,
and prepares for the possibility of underlying decls with a different name
from the found decl.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256575 91177308-0d34-0410-b5e6-96231b3b80d8
is complete (with an error produced if not) and a function that merely queries
whether the type is complete. Either way we'll trigger instantiation if
necessary, but only the former will diagnose and recover from missing module
imports.
The intent of this change is to prevent a class of bugs where code would call
RequireCompleteType(..., 0) and then ignore the result. With modules, we must
check the return value and use it to determine whether the definition of the
type is visible.
This also fixes a debug info quality issue: calls to isCompleteType do not
trigger the emission of debug information for a type in limited-debug-info
mode. This allows us to avoid emitting debug information for type definitions
in more cases where we believe it is safe to do so.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256049 91177308-0d34-0410-b5e6-96231b3b80d8
`pass_object_size` is our way of enabling `__builtin_object_size` to
produce high quality results without requiring inlining to happen
everywhere.
A link to the design doc for this attribute is available at the
Differential review link below.
Differential Revision: http://reviews.llvm.org/D13263
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254554 91177308-0d34-0410-b5e6-96231b3b80d8
Also address a typo from a prior patch that performed a similar fix during Parsing of default non-type template arguments. I left the RAII ExpressionEvaluationContext variable Name as Unevaluated though we had switched the context to ConstantEvaluated.
There should be no functionality change here - since when expression evaluation context is popped off, for the most part these two contexts currently behave similarly in regards to lambda diagnostics and odr-use tracking.
Like its parsing counterpart, this patch presages the advent of constexpr lambda patches...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253590 91177308-0d34-0410-b5e6-96231b3b80d8
We created a malformed TemplateSpecializationType: it was dependent but
had a RecordType as it's canonical type. This would lead getAs to
crash. r249090 worked around this but we should fix this for real by
providing a more appropriate template specialization type as the
canonical type.
This fixes PR24246.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253495 91177308-0d34-0410-b5e6-96231b3b80d8
This new builtin template allows for incredibly fast instantiations of
templates like std::integer_sequence.
Performance numbers follow:
My work station has 64 GB of ram + 20 Xeon Cores at 2.8 GHz.
__make_integer_seq<std::integer_sequence, int, 90000> takes 0.25
seconds.
std::make_integer_sequence<int, 90000> takes unbound time, it is still
running. Clang is consuming gigabytes of memory.
Differential Revision: http://reviews.llvm.org/D13786
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252036 91177308-0d34-0410-b5e6-96231b3b80d8
partial specialization can perform conversions on the argument. Be sure we
start again from the original argument when checking each possible template.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249114 91177308-0d34-0410-b5e6-96231b3b80d8
We used to only select an inheritance model if the pointer to member was
nullptr. Instead, select a model regardless of the member pointer's
value.
N.B. This bug was exposed by making member pointers report true for
isIncompleteType but has been latent since the member pointer scheme's
inception.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247464 91177308-0d34-0410-b5e6-96231b3b80d8
non-visible definition, skip the new definition to avoid ending up with a
function with multiple definitions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245664 91177308-0d34-0410-b5e6-96231b3b80d8
It's possible for TagRedeclarations to involve decls without a name,
ie, anonymous enums. We hit some undefined behaviour if we bind these
null names to the reference here.
We never dereference the name, so it's harmless if it's null - make it
a pointer to allow that.
Fixes the Modules/submodules-merge-defs.cpp test under ubsan.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241963 91177308-0d34-0410-b5e6-96231b3b80d8
an existing using shadow declaration if they define entities of the same kind
in different namespaces.
We'd previously check this consistently if the using-declaration came after the
other declaration, but not if it came before.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241428 91177308-0d34-0410-b5e6-96231b3b80d8
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8
modules, and allow use of a default template argument if any of the parameters
providing it is visible.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239485 91177308-0d34-0410-b5e6-96231b3b80d8
This is just a preparatory step towards fixing visibility for default template
arguments in modules builds.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239447 91177308-0d34-0410-b5e6-96231b3b80d8
This is a follow-up to r225570 which enabled adding DLL attributes when a
class template goes from explicit instantiation declaration to explicit
instantiation definition.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239375 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, we wouldn't call checkDLLAttribute() after the class template
specialization definition if the class template was already instantiated
by an explicit class template specialization declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238266 91177308-0d34-0410-b5e6-96231b3b80d8
Clang was inserting these into a dense map. While it never iterated the
dense map during normal compilation, it did when emitting a module. Fix
this by using a standard MapVector to preserve the order in which we
encounter the late parsed templates.
I suspect this still isn't ideal, as we don't seem to remove things from
this map even when we mark the templates as no longer late parsed. But
I don't know enough about this particular extension to craft a nice,
subtle test case covering this. I've managed to get the stress test to
at least do some late parsing and demonstrate the core problem here.
This patch fixes the test and provides deterministic behavior which is
a strict improvement over the prior state.
I've cleaned up some of the code here as well to be explicit about
inserting when that is what is actually going on.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233264 91177308-0d34-0410-b5e6-96231b3b80d8
MS compiler emits no errors in case of explicit specializations outside declaration enclosing namespaces, even when language extensions are disabled.
The patch is to suppress errors and emit extension warnings if explicit specializations are not declared in the corresponding namespaces.
This fixes PR13738.
Patch by Alexey Frolov.
Differential Revision: http://reviews.llvm.org/D8283
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232800 91177308-0d34-0410-b5e6-96231b3b80d8
and only update the orginal list on a valid arugment list. When checking an
individual expression template argument, and conversions are required, update
the expression in the template argument. Since template arguments are
speculatively checked, the copying of the template argument list prevents
updating the template arguments when the list does not match the template.
Additionally, clean up the integer checking code in the template diffing code.
The code performs unneccessary conversions from APSInt to APInt.
Fixes PR21758.
This essentially reverts r224770 to recommits r224667 and r224668 with extra
changes to prevent the template instantiation problems seen in PR22006.
A test to catch the discovered problem is also added.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226983 91177308-0d34-0410-b5e6-96231b3b80d8
Clang would previously become confused and crash here.
It does not make a lot of sense to export these, so warning seems appropriate.
MSVC will export some member functions for this kind of specializations, whereas
MinGW ignores the dllexport-edness. The latter behaviour seems better.
Differential Revision: http://reviews.llvm.org/D6984
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226208 91177308-0d34-0410-b5e6-96231b3b80d8
r224667 broke bootstrap on Fedora 20 X86_64 (at least).
See pr22006 for the details.
r224668 depends on r224667.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224770 91177308-0d34-0410-b5e6-96231b3b80d8
When a non-type template argument expression needs a conversion to change it
into the argument type, preserve that information by remaking the
TemplateArgument with an expression that has those conversions. Also a small
fix to template type diffing to handle the extra conversions in some cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224667 91177308-0d34-0410-b5e6-96231b3b80d8
Consider a template class with attributes on a method, and an explicit
specialization of that method:
template <int>
struct A {
void foo() final;
};
template <>
void A<0>::foo() {}
In this example, the attribute is `final`, but it might also be an
__attribute__((visibility("foo"))), noreturn, inline, etc. clang's current
behavior is to strip all attributes, which for some attributes is wrong
(the snippet above allows a subclass of A<0> to override the final method, for
example) and for others disagrees with gcc.
So stop dropping attributes. r95845 added this code without a test case, and
r176728 added the code for dropping attributes on parameters (with tests, but
they still pass).
As an additional wrinkle, do drop dllimport and dllexport, since that's how
these two attributes work. (This is covered by existing tests.)
Fixes PR21942.
The approach is by Richard Smith, initial analysis and typing was done by me.
With this, clang also matches GCC and EDG on all attributes Richard tested.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224651 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r224451. It caused us to reject some valid existing
code.
This code appears to run in non-error cases as well as error cases. If
the scope of a DependentScopeDeclRefExpr is still incomplete it probably
means we still have more instantiation to do.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224526 91177308-0d34-0410-b5e6-96231b3b80d8
exact type match for deduced template arguments, and be sure to produce correct
canonical TemplateArgument representations to enable correct redeclaration
matching.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224456 91177308-0d34-0410-b5e6-96231b3b80d8
A DependentScopeDeclRefExpr should always have a nested name specifier.
During template instantiation, if we found that the named context was
incomplete, we would previously build a DependentScopeDeclRefExpr with
an empty qualifier.
This error recovery path has been asserting for some time. The other
error codepaths use ExprError, so we can do the same.
Fixes PR21864.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224451 91177308-0d34-0410-b5e6-96231b3b80d8
We don't yet support pointer-to-member template arguments that have undergone
pointer-to-member conversions, mostly because we don't have a mangling for them yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222807 91177308-0d34-0410-b5e6-96231b3b80d8
expansion into a parameter pack; we know that we're still filling in that
parameter's arguments. Previously, if we hit this case for an alias template,
we'd try to substitute using non-canonical template arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221832 91177308-0d34-0410-b5e6-96231b3b80d8
penultimate parameter of a template parameter list, where the last parameter is
itself a pack, and build a bogus empty final pack argument.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221748 91177308-0d34-0410-b5e6-96231b3b80d8
According to C++ standard if an exception-specification is specified in an explicit instantiation directive, it shall be compatible with the exception-specifications of other declarations of that function. This patch adds checks for this.
Differential Revision: http://reviews.llvm.org/D5822
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221448 91177308-0d34-0410-b5e6-96231b3b80d8
Plumb through the full QualType of the TemplateArgument::Declaration, as
it's insufficient to only know whether the type is a reference or
pointer (that was necessary for mangling, but insufficient for debug
info). This shouldn't increase the size of TemplateArgument as
TemplateArgument::Integer is still longer by another 32 bits.
Several bits of code were testing that the reference-ness of the
parameters matched, but this seemed to be insufficient (various other
features of the type could've mismatched and wouldn't've been caught)
and unnecessary, at least insofar as removing those tests didn't cause
anything to fail.
(Richard - perchaps you can hypothesize why any of these checks might
need to test reference-ness of the parameters (& explain why
reference-ness is part of the mangling - I would've figured that for the
reference-ness to be different, a prior template argument would have to
be different). I'd be happy to add them in/beef them up and add test
cases if there's a reason for them)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219900 91177308-0d34-0410-b5e6-96231b3b80d8
We build a NestedNameSpecifier that records the CXXRecordDecl in which
__super appeared. Name lookup is performed in all base classes of the
recorded CXXRecordDecl. Use of __super is allowed only inside class and
member function scope.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218484 91177308-0d34-0410-b5e6-96231b3b80d8
The warning warns on TypedefNameDecls -- typedefs and C++11 using aliases --
that are !isReferenced(). Since the isReferenced() bit on TypedefNameDecls
wasn't used for anything before this warning it wasn't always set correctly,
so this patch also adds a few missing MarkAnyDeclReferenced() calls in
various places for TypedefNameDecls.
This is made a bit complicated due to local typedefs possibly being used only
after their local scope has closed. Consider:
template <class T>
void template_fun(T t) {
typename T::Foo s3foo; // YYY
(void)s3foo;
}
void template_fun_user() {
struct Local {
typedef int Foo; // XXX
} p;
template_fun(p);
}
Here the typedef in XXX is only used at end-of-translation unit, when YYY in
template_fun() gets instantiated. To handle this, typedefs that are unused when
their scope exits are added to a set of potentially unused typedefs, and that
set gets checked at end-of-TU. Typedefs that are still unused at that point then
get warned on. There's also serialization code for this set, so that the
warning works with precompiled headers and modules. For modules, the warning
is emitted when the module is built, for precompiled headers each time the
header gets used.
Finally, consider a function using C++14 auto return types to return a local
type defined in a header:
auto f() {
struct S { typedef int a; };
return S();
}
Here, the typedef escapes its local scope and could be used by only some
translation units including the header. To not warn on this, add a
RecursiveASTVisitor that marks all delcs on local types returned from auto
functions as referenced. (Except if it's a function with internal linkage, or
the decls are private and the local type has no friends -- in these cases, it
_is_ safe to warn.)
Several of the included testcases (most of the interesting ones) were provided
by Richard Smith.
(gcc's spelling -Wunused-local-typedefs is supported as an alias for this
warning.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217298 91177308-0d34-0410-b5e6-96231b3b80d8
declared, rather than putting them into the template parameter scope. We
previously had *no record* in the scope for class template declarations, once
those declarations completed and their template parameter scopes were popped.
This in turn caused us to be unable to merge class template declarations that
were declared in the global scope (where we use scope lookup rather than
DeclContext lookup for merging), when loading a module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216311 91177308-0d34-0410-b5e6-96231b3b80d8
ExtWarn/Warnings. Mostly the name of the warning was changed to match the
semantics, but in the PR20356 cases, the warning was about valid code, so the
diagnostic was changed from ExtWarn to Warning instead.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213443 91177308-0d34-0410-b5e6-96231b3b80d8
Previously dllimport variables inside of template arguments relied on
not using the C++11 codepath when -fms-compatibility was set.
While this allowed us to achieve compatibility with MSVC, it did so at
the expense of MingW.
Instead, try to use the DeclRefExpr we dig out of the template argument.
If it has the dllimport attribute, accept it and skip the C++11
null-pointer check.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211766 91177308-0d34-0410-b5e6-96231b3b80d8
This is a follow-up to David's r211677. For the following code,
we would end up referring to 'foo' in the initializer for 'arr',
and then fail to link, because 'foo' is dllimport and needs to be
accessed through the __imp_?foo.
__declspec(dllimport) extern const char foo[];
const char* f() {
static const char* const arr[] = { foo };
return arr[0];
}
Differential Revision: http://reviews.llvm.org/D4299
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211736 91177308-0d34-0410-b5e6-96231b3b80d8
The compilation pipeline doesn't actually need to know about the high-level
concept of diagnostic mappings, and hiding the final computed level presents
several simplifications and other potential benefits.
The only exceptions are opportunistic checks to see whether expensive code
paths can be avoided for diagnostics that are guaranteed to be ignored at a
certain SourceLocation.
This commit formalizes that invariant by introducing and using
DiagnosticsEngine::isIgnored() in place of individual level checks throughout
lex, parse and sema.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211005 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
'sizeof' is a UnaryExprOrTypeTrait, and it can contain either a type or
an expression. This change threads a RecoveryTSI parameter through the
layers between TransformUnaryExprOrTypeTrait the point at which we look
up the type. If lookup finds a single type result after instantiation,
we now build TypeSourceInfo for it just like a normal transformation
would.
This fixes the last error in the hello world ATL app that I've been
working with, and it now links and runs with clang. Please try it and
file bugs!
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4108
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210855 91177308-0d34-0410-b5e6-96231b3b80d8
While matching a non-type template argument against a known template
type parameter we now modify the AST's TemplateArgumentLoc to assume the
user wrote typename. Under -fms-compatibility, we downgrade our
diagnostic from an error to an extwarn.
Reviewed by: rsmith
Differential Revision: http://reviews.llvm.org/D4049
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210607 91177308-0d34-0410-b5e6-96231b3b80d8
results in a template having too many arguments, but all the trailing arguments
are packs, that's OK if we have a partial pack substitution: the trailing pack
expansions may end up empty.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210350 91177308-0d34-0410-b5e6-96231b3b80d8
gets explicitly specialized, don't reuse the previous class template
specialization declaration as a new declaration. The benefit here is fairly
marginal, it harms source fidelity, and this is horrible to model if the
specialization was imported from another module (without this change, it
asserts or worse).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209552 91177308-0d34-0410-b5e6-96231b3b80d8
A template declaration of a template name can be null in case we have a dependent name or a set of function templates.
Hence use dyn_cast_or_null instead of dyn_cast. Also improve the diagnostic emitted in this case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208313 91177308-0d34-0410-b5e6-96231b3b80d8
after we've already instantiated a definition for the function, pass it to the
ASTConsumer again so that it knows the specialization kind has changed and can
update the function's linkage.
This only matters if we instantiate the definition of the function before we
reach the end of the TU; this can happen in at least three different ways:
C++11 constexpr functions, C++14 deduced return types, and functions
instantiated within modules.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207152 91177308-0d34-0410-b5e6-96231b3b80d8
clang\lib\Sema\SemaTemplate.cpp(1826) : error C2064: term does not evaluate to a function taking 1 arguments
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206451 91177308-0d34-0410-b5e6-96231b3b80d8
that looks like it might be an explicit specialization, don't recover as an
explicit specialization (bypassing the check that would reject that).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206444 91177308-0d34-0410-b5e6-96231b3b80d8
For namespaces, this is consistent with mangling and GCC's debug info
behavior. For structs, GCC uses <anonymous struct> but we prefer
consistency between all anonymous entities but don't want to confuse
them with template arguments, etc, so we'll just go with parens in all
cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205398 91177308-0d34-0410-b5e6-96231b3b80d8
template parameters, don't look for parameters of outer templates. If a problem
is found in a default template argument, point the diagnostic at the partial
specialization (with a note pointing at the default argument) instead of
pointing it at the default argument and leaving it unclear which partial
specialization os problematic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201031 91177308-0d34-0410-b5e6-96231b3b80d8
Properly determine the inheritance model when dealing with nullptr:
- If a nullptr template argument is being checked against
pointer-to-member parameter, nail down an inheritance model.
N.B. We will chose an inheritance model even if we won't ultimately
choose the template to instantiate! Cooky, right?
- Null pointer-to-datamembers have a virtual base table offset of -1,
not zero. Previously, we chose an offset of 0.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200920 91177308-0d34-0410-b5e6-96231b3b80d8
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200082 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199686 91177308-0d34-0410-b5e6-96231b3b80d8
Reid Kleckner