| Age | Commit message (Collapse) | Author |
|---|
|
------------------------------------------------------------------------
r324537 | rsmith | 2018-02-07 23:25:16 +0100 (Wed, 07 Feb 2018) | 14 lines
PR36055: fix computation of *-dependence in nested initializer lists.
When we synthesize an implicit inner initializer list when analyzing an outer
initializer list, we add it to the outer list immediately, and then fill in the
inner list. This gives the outer list no chance to update its *-dependence bits
with those of the completed inner list. To fix this, re-add the inner list to
the outer list once it's completed.
Note that we do not recompute the *-dependence bits from scratch when we
complete an outer list; this would give the wrong result for the case where a
designated initializer overwrites a dependent initializer with a non-dependent
one. The resulting list in that case should still be dependent, even though all
traces of the dependence were removed from the semantic form.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_60@324719 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r321777 | rsmith | 2018-01-03 17:02:18 -0800 (Wed, 03 Jan 2018) | 2 lines
PR35028: Retain duplicate alignas attributes in template instantiation.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_60@322676 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r322236 | rsmith | 2018-01-10 15:08:26 -0800 (Wed, 10 Jan 2018) | 3 lines
In C++17, when instantiating an out-of-line definition of an inline static data
member, don't forget to instantiate the initializer too.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_60@322641 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
system header.
The way to fix an undefined-template warning is to add lines to the header file that defines the template pattern. We should suppress the warnings when the template pattern is in a system header because we don't expect users to edit those.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321665 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
An unscoped enumeration used as template argument, should not have any
qualified information about its enclosing scope, as its visibility is
global.
In the case of scoped enumerations, they must include information
about their enclosing scope.
Patch by Carlos Alberto Enciso!
Differential Revision: https://reviews.llvm.org/D39239
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321312 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms.
Fixes the -Wreorder issue and fixes the ast-dump-color.cpp test.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321310 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Otherwise it will serve as a deduction guide for the wrong class template.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321297 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Misc/ast-dump-color.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321229 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321223 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
update the type from the definition even if we didn't instantiate a definition.
We may have instantiated the definition in an earlier stage of semantic
analysis, after creating the DeclRefExpr but before we reach a point where a
complete expression type is required.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320709 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Adding the new enumerator forced a bunch more changes into this patch than I
would have liked. The -Wtautological-compare warning was extended to properly
check the new comparison operator, clang-format needed updating because it uses
precedence levels as weights for determining where to break lines (and several
operators increased their precedence levels with this change), thread-safety
analysis needed changes to build its own IL properly for the new operator.
All "real" semantic checking for this operator has been deferred to a future
patch. For now, we use the relational comparison rules and arbitrarily give
the builtin form of the operator a return type of 'void'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320707 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is C++14 with conforming GNU extensions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320250 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of its argument, perform function-to-pointer and array-to-pointer decay on the
parameter type first.
Otherwise deduction will fail, as the type of the argument will be decayed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319584 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
deduction for invalid functions
The fabricated template parameters cause an assertion because their depth
is invalid.
rdar://34109988
Differential Revision: https://reviews.llvm.org/D37341
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316778 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
constant expressions.
We permit array-to-pointer decay on such arrays, but disallow pointer
arithmetic (since we do not know whether it will have defined behavior).
This is based on r311970 and r301822 (the former by me and the latter by Robert
Haberlach). Between then and now, two things have changed: we have committee
feedback indicating that this is indeed the right direction, and the code
broken by this change has been fixed.
This is necessary in C++17 to continue accepting certain forms of non-type
template argument involving arrays of unknown bound.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316245 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instantiation declarations if they are usable from constant expressions.
We are permitted to instantiate in these cases, and required to do so in order
to have an initializer available for use within constant evaluation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316136 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Currently Clang uses default address space (0) to represent private address space for OpenCL
in AST. There are two issues with this:
Multiple address spaces including private address space cannot be diagnosed.
There is no mangling for default address space. For example, if private int* is emitted as
i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as
Pi instead.
This patch attempts to represent OpenCL private address space explicitly in AST. It adds
a new enum LangAS::opencl_private and adds it to the variable types which are implicitly
private:
automatic variables without address space qualifier
function parameter
pointee type without address space qualifier (OpenCL 1.2 and below)
Differential Revision: https://reviews.llvm.org/D35082
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315668 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Modifying a non-type template integer arguement that is causing errors
in some builds as it's too large for 32-bit longs. This hopefully (and
seems to when testing) should fix all of the build bot errors relating
to this test. I also modified the name of the function call to be more
apt.
Differential Revision: https://reviews.llvm.org/D33666
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314668 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Adding regression test for Dependent Address Spaces in relation to
https://reviews.llvm.org/D33666 I forgot to svn add the test file
before commiting the prior changes. I appologies.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314650 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
know are going to be constant-evaluated.
Any relevant diagnostics should be produced by constant expression evaluation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314067 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
variable templates.
This implements the proposed approach in https://github.com/itanium-cxx-abi/cxx-abi/issues/33
This reinstates r313827, reverted in r313856, with a fix for the 'out-of-bounds
enumeration value' ubsan error in that change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@313955 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@313943 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Sema::InstantiateClass should check only exception specs added during
class instantiation and ignore already present delayed specs. This fixes
a case where we instantiate a class before parsing member initializers,
check exceptions for a different class and fail to find a member
initializer. Which is required for comparing exception specs for
explicitly-defaulted and implicit default constructor. With the fix we
are still checking exception specs but only after member initializers
are present.
Removing errors in crash-unparsed-exception.cpp is acceptable according
to discussion in PR24000 because other compilers accept code in
crash-unparsed-exception.cpp as valid.
rdar://problem/34167492
Reviewers: davide, rsmith
Reviewed By: rsmith
Subscribers: dim, cfe-commits
Differential Revision: https://reviews.llvm.org/D37881
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@313906 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
variables and variable templates."
To fix: runtime error: load of value 15, which is not a valid value for type 'clang::LVComputationKind'
This reverts commit r313827.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@313856 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
variable templates.
This implements the proposed approach in https://github.com/itanium-cxx-abi/cxx-abi/issues/33
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@313827 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
recent (non-friend) declaration to pick up the right set of default template
arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312049 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@310804 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@309118 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@307202 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@307197 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
When enable_if disables a particular overload resolution candidate,
rummage through the enable_if condition to find the specific condition
that caused the failure. For example, if we have something like:
template<
typename Iter,
typename = std::enable_if_t<Random_access_iterator<Iter> &&
Comparable<Iterator_value_type<Iter>>>>
void mysort(Iter first, Iter last) {}
and we call "mysort" with "std::list<int>" iterators, we'll get a
diagnostic saying that the "Random_access_iterator<Iter>" requirement
failed. If we call "mysort" with
"std::vector<something_not_comparable>", we'll get a diagnostic saying
that the "Comparable<...>" requirement failed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@307196 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This patch aims to fix the bug reported at
https://bugs.llvm.org/show_bug.cgi?id=33189. Clang hits an assertion
when a template destructor declaration is present. This is caused by
later processing that does not expect to encounter a template when
looking at a destructor. The resolution is to treat the destructor as
being not declared when later processing is interested in the properties
of the destructor of a class.
Reviewers: rcraik, hubert.reinterpretcast, aaron.ballman, rsmith
Reviewed By: rsmith
Subscribers: rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D33833
Patch by Kuang He!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@306905 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is not required by the standard (yet), but there seems to be reasonable
support for this being a defect according to CWG discussion, and libstdc++ 7.1
relies on it working.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@304946 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template is valid with or without it (with different meanings).
If we see "dependent.x<...", and what follows the '<' is a valid expression,
we must parse the '<' as a comparison rather than a template angle bracket.
When we later come to instantiate, if we find that the LHS of the '<' actually
names an overload set containing function templates, produce a diagnostic
suggesting that the 'template' keyword was missed rather than producing a
mysterious diagnostic saying that the function must be called (and pointing
at what looks to already be a function call!).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@304852 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This fixes missing lambda-captures for variables referenced only inside a
static_assert (!), among other things.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@304760 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template partial specialization.
In passing, fix the deduction-crash.cpp test to actually run all the tests. Due
to a typo, the last third of the file was being skipped by the parser and some
of the tests were not actually testing anything as a result. Switch from
FileCheck to -verify to make the problem more obvious and prevent this
happening again.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@304604 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
When an undeclared identifier in a context that requires a type is followed by
'<', only look for type templates when typo-correcting, tweak the diagnostic
text to say that a template name (not a type name) was undeclared, and parse
the template arguments when recovering from the error.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@302732 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template-id.
The heuristic that we use here is:
* the left-hand side must be a simple identifier or a class member access
* the right-hand side must be '<' followed by either a '>' or by a type-id that
cannot be an expression (in particular, not followed by '(' or '{')
* there is a '>' token matching the '<' token
The second condition guarantees the expression would otherwise be ill-formed.
If we're confident that the user intended the name before the '<' to be
interpreted as a template, diagnose the fact that we didn't interpret it
that way, rather than diagnosing that the template arguments are not valid
expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@302615 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
default template arguments from other declarations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@302603 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the specialization.
This improves our behavior in a few ways:
* We now guarantee that if a member is marked as being a member
specialization, there will actually be a member specialization declaration
somewhere on its redeclaration chain. This fixes a crash in modules builds
where we would try to check that there was a visible declaration of the
member specialization and be surprised to not find any declaration of it at
all.
* We don't set the source location of the in-class declaration of the member
specialization to the out-of-line declaration's location until we have
actually finished merging them. This fixes some very silly looking
diagnostics, where we'd point a "previous declaration is here" note at the
same declaration we're complaining about. Ideally we wouldn't mess with the
prior declaration's location at all, but too much code assumes that the
first declaration of an entity is a reasonable thing to use as an indication
of where it was declared, and that's not really true for a member
specialization unless we fake it like this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@302596 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
properly replace a friend, and a visible friend can properly replace an invisible friend but not vice verse, and definitions are not replaced. This fixes the two FIXME in SemaTemplate/friend-template.cpp."
This reverts commit r300443. Breaks compiling libc++ with modules in
some configurations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300497 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
replace a friend, and a visible friend can properly replace an invisible friend but not vice verse, and definitions are not replaced. This fixes the two FIXME in SemaTemplate/friend-template.cpp.
The code implements Richard Smith suggestion in comment 3 of the PR.
reviewer: Vassil Vassilev
Differential Revision: https://reviews.llvm.org/D31540
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300443 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts an attempt to check that types match when matching a
dependently-typed non-type template parameter. (This comes up when matching the
parameters of a template template parameter against the parameters of a
template template argument.)
The matching rules here are murky at best. Our behavior after this revert is
definitely wrong for certain C++17 features (for 'auto' template parameter
types within the parameter list of a template template argument in particular),
but our behavior before this revert is wrong for some pre-existing testcases,
so reverting to our prior behavior seems like our best option.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300262 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Printing typedefs or type aliases using clang_getTypeSpelling() is missing the
namespace they are defined in. This is in contrast to other types that always
yield the full typename including namespaces.
Patch by Michael Reiher!
Differential Revision: https://reviews.llvm.org/D29944
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@297465 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
[Test] Make Lit tests C++11 compatible #9
Differential Revision: https://reviews.llvm.org/D20710
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@296184 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
compiler is run in a mode where the default C++ standard is newer than C++03.
The reason is because one of the warnings checked is only produced when the
compiler is using C++03 or lower.
This change fixes this problem as well as adds explicit run lines to run the
test in C++03 and C++11 modes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@296066 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
A 'decltype(auto)' parameter can match any other kind of non-type template
parameter, so should be usable in place of any other parameter in a template
template argument. The standard is sadly extremely unclear on how this is
supposed to work, but this seems like the obviously-correct result.
It's less clear whether an 'auto' parameter should be able to match
'decltype(auto)', since the former cannot be used if the latter turns out to be
used for a reference type, but if we disallow that then consistency suggests we
should also disallow 'auto' matching 'T' for the same reason, defeating
intended use cases of the feature.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295866 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We need to look through the PackExpansionType in the parameter type when
deducing, and we need to consider the possibility of deducing arguments for
packs that are not lexically mentioned in the pattern (but are nonetheless
deducible) when figuring out which packs are covered by a pack deduction scope.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295790 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
assume the bound has a non-dependent integral type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295698 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295696 91177308-0d34-0410-b5e6-96231b3b80d8
|
