This reverts commit 275f30df8a.
As noted on the code review (https://reviews.llvm.org/D92892), this
change causes us to reject valid code in a few cases. Reverting so we
have more time to figure out what the right fix{es are, is} here.
Combined with 'da98651 - Revert "DR2064:
decltype(E) is only a dependent', this change (5a391d3) caused verifier
errors when building Chromium. See https://crbug.com/1168494#c1 for a
reproducer.
Additionally it reverts changes that were dependent on this one, see
below.
> Following up on PR48517, fix handling of template arguments that refer
> to dependent declarations.
>
> Treat an id-expression that names a local variable in a templated
> function as being instantiation-dependent.
>
> This addresses a language defect whereby a reference to a dependent
> declaration can be formed without any construct being value-dependent.
> Fixing that through value-dependence turns out to be problematic, so
> instead this patch takes the approach (proposed on the core reflector)
> of allowing the use of pointers or references to (but not values of)
> dependent declarations inside value-dependent expressions, and instead
> treating template arguments as dependent if they evaluate to a constant
> involving such dependent declarations.
>
> This ends up affecting a bunch of OpenMP tests, due to OpenMP
> imprecisely handling instantiation-dependent constructs, bailing out
> early instead of processing dependent constructs to the extent possible
> when handling the template.
>
> Previously committed as 8c1f2d15b8, and
> reverted because a dependency commit was reverted.
This reverts commit 5a391d38ac.
It also restores clang/test/SemaCXX/coroutines.cpp to its state before
da986511fb.
Revert "[c++20] P1907R1: Support for generalized non-type template arguments of scalar type."
> Previously committed as 9e08e51a20, and
> reverted because a dependency commit was reverted. This incorporates the
> following follow-on commits that were also reverted:
>
> 7e84aa1b81 by Simon Pilgrim
> ed13d8c667 by me
> 95c7b6cadb by Sam McCall
> 430d5d8429 by Dave Zarzycki
This reverts commit 4b574008ae.
Revert "[msabi] Mangle a template argument referring to array-to-pointer decay"
> [msabi] Mangle a template argument referring to array-to-pointer decay
> applied to an array the same as the array itself.
>
> This follows MS ABI, and corrects a regression from the implementation
> of generalized non-type template parameters, where we "forgot" how to
> mangle this case.
This reverts commit 18e093faf7.
applied to an array the same as the array itself.
This follows MS ABI, and corrects a regression from the implementation
of generalized non-type template parameters, where we "forgot" how to
mangle this case.
if E is merely instantiation-dependent."
This change leaves us unable to distinguish between different function
templates that differ in only instantiation-dependent ways, for example
template<typename T> decltype(int(T())) f();
template<typename T> decltype(int(T(0))) f();
We'll need substantially better support for types that are
instantiation-dependent but not dependent before we can go ahead with
this change.
This reverts commit e3065ce238.
Previously committed as 9e08e51a20, and
reverted because a dependency commit was reverted. This incorporates the
following follow-on commits that were also reverted:
7e84aa1b81 by Simon Pilgrim
ed13d8c667 by me
95c7b6cadb by Sam McCall
430d5d8429 by Dave Zarzycki
to dependent declarations.
Treat an id-expression that names a local variable in a templated
function as being instantiation-dependent.
This addresses a language defect whereby a reference to a dependent
declaration can be formed without any construct being value-dependent.
Fixing that through value-dependence turns out to be problematic, so
instead this patch takes the approach (proposed on the core reflector)
of allowing the use of pointers or references to (but not values of)
dependent declarations inside value-dependent expressions, and instead
treating template arguments as dependent if they evaluate to a constant
involving such dependent declarations.
This ends up affecting a bunch of OpenMP tests, due to OpenMP
imprecisely handling instantiation-dependent constructs, bailing out
early instead of processing dependent constructs to the extent possible
when handling the template.
Previously committed as 8c1f2d15b8, and
reverted because a dependency commit was reverted.
the nested-name-specifier when determining whether a qualified type is
instantiation-dependent.
Previously reverted in 25a02c3d1a due to
causing us to reject some code. It turns out that the rejected code was
ill-formed (no diagnostic required).
if E is merely instantiation-dependent.
Previously reverted in 34e72a146111dd986889a0f0ec8767b2ca6b2913;
re-committed with a fix to an issue that caused name mangling to assert.
The C++ standard wording doesn't appear to properly handle the case
where a class inherits a default constructor from a base class. Various
properties of classes are defined in terms of the corresponding property
of the default constructor, and in this case, the class does not have a
default constructor despite being default-constructible, which the
wording doesn't handle properly.
This change implements a tentative fix for these problems, which has
also been proposed to the C++ committee: if a class would inherit a
default constructor, and does not explicitly declare one, then one is
implicitly declared.
The check only runs in debug mode during serialization, but
assert()-fail on:
struct S { const int& x = 7; };
in C++ mode.
Differential Revision: https://reviews.llvm.org/D94804
Currently, there are many instances where `SourceLocation` objects are
converted to raw representation to be stored in structs that are
used as fields of tagged unions.
This is done to make the corresponding structs trivial.
Triviality allows avoiding undefined behavior when implicitly changing
the active member of the union.
However, in most cases, we can explicitly construct an active member
using placement new. This patch adds the required active member
selections and replaces `SourceLocation`-s represented as
`unsigned int` with proper `SourceLocation`-s.
One notable exception is `DeclarationNameLoc`: the objects of this class
are often not properly initialized (so the code currently relies on
its default constructor which uses memset). This class will be fixed
in a separate patch.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D94237
This code currently uses a union object to increase the
alignment of the type ObjCTypeParamList. The original intent of this
trick was to be able to use the expression `this + 1` to access the
beginning of a tail-allocated array of `ObjCTypeParamDecl *` pointers.
The code has since been refactored and uses `llvm::TrailingObjects` to
manage the tail-allocated array. This template takes care of
alignment, so the hack is no longer necessary.
This patch removes the union so that the `SourceRange` class can be
used directly instead of being re-implemented with raw representations
of source locations.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D94224
When printing QualType with qualifiers like "const", or pointing to an
elaborated type, we would print garbage like:
std::const std::vector<int>&
with the initial std:: being calculated correctly, but inserted in the
wrong place and the second std:: not removed (due to elaborated type).
This affected, among others, ExtractFunction and ExpandAuto tweaks.
This change introduces a new callback to PrintingPolicy, which allows us
to influence the printing of namespace qualifiers. In the future, the
same callback can be used to improve handling of "using namespace"
directives as well.
Fixes:
https://github.com/clangd/clangd/issues/640 (ExtractFunction)
https://github.com/clangd/clangd/issues/264 (ExpandAuto)
First point of https://github.com/clangd/clangd/issues/524
Differential Revision: https://reviews.llvm.org/D94259
This patch adds support for two new variants of the vectorize_width
pragma:
1. vectorize_width(X[, fixed|scalable]) where an optional second
parameter is passed to the vectorize_width pragma, which indicates if
the user wishes to use fixed width or scalable vectorization. For
example the user can now write something like:
#pragma clang loop vectorize_width(4, fixed)
or
#pragma clang loop vectorize_width(4, scalable)
In the absence of a second parameter it is assumed the user wants
fixed width vectorization, in order to maintain compatibility with
existing code.
2. vectorize_width(fixed|scalable) where the width is left unspecified,
but the user hints what type of vectorization they prefer, either
fixed width or scalable.
I have implemented this by making use of the LLVM loop hint attribute:
llvm.loop.vectorize.scalable.enable
Tests were added to
clang/test/CodeGenCXX/pragma-loop.cpp
for both the 'fixed' and 'scalable' optional parameter.
See this thread for context: http://lists.llvm.org/pipermail/cfe-dev/2020-November/067262.html
Differential Revision: https://reviews.llvm.org/D89031
Motivating example:
```
struct { int v[10]; } t[10];
__builtin_object_size(
&t[0].v[11], // access past end of subobject
1 // request remaining bytes of closest surrounding
// subobject
);
```
In GCC, this returns 0. https://godbolt.org/z/7TeGs7
In current clang, however, this returns 356, the number of bytes
remaining in the whole variable, as if the `type` was 0 instead of 1.
https://godbolt.org/z/6Kffox
This patch checks for the specific case where we're requesting a
subobject's size (type 1) but the subobject is invalid.
Differential Revision: https://reviews.llvm.org/D92892
The assertion can happen if ASTImporter imports a CXXRecordDecl in a template
and then imports another redeclaration of this declaration, while the first import is in progress.
The process of first import did not set the "described template" yet
and the second import finds the first declaration at setting the injected types.
Setting the injected type requires in the assertion that the described template is set.
The exact assertion was:
clang/lib/AST/ASTContext.cpp:4411:
clang::QualType clang::ASTContext::getInjectedClassNameType(clang::CXXRecordDecl*, clang::QualType) const:
Assertion `NeedsInjectedClassNameType(Decl)' failed.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D94067
The implementation for (de)serialization of APValues can be shared
between Clang and Swift, so we prefer pushing the methods up
the inheritance hierarchy, instead of having the methods live in
ASTReader/ASTWriter. Fixes rdar://72592937.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D94196
getAs<> can return null if the cast is invalid, which can lead to null pointer deferences. Use castAs<> instead which will assert that the cast is valid.
function when the receiver is nil
Callee-destroyed arguments to a method have to be destroyed in the
caller function when the receiver is nil as the method doesn't get
executed. This fixes PR48207.
rdar://71808391
Differential Revision: https://reviews.llvm.org/D93273
to dependent declarations.
Treat an id-expression that names a local variable in a templated
function as being instantiation-dependent.
This addresses a language defect whereby a reference to a dependent
declaration can be formed without any construct being value-dependent.
Fixing that through value-dependence turns out to be problematic, so
instead this patch takes the approach (proposed on the core reflector)
of allowing the use of pointers or references to (but not values of)
dependent declarations inside value-dependent expressions, and instead
treating template arguments as dependent if they evaluate to a constant
involving such dependent declarations.
This ends up affecting a bunch of OpenMP tests, due to OpenMP
imprecisely handling instantiation-dependent constructs, bailing out
early instead of processing dependent constructs to the extent possible
when handling the template.
dependent until it's been converted to match its parameter.
The type of a non-type template parameter can in general affect whether
the template argument is dependent.
Note that this is not always possible. For template arguments that name
static local variables in templates, the type of the template parameter
affects whether the argument is dependent, so the query is imprecise
until we know the parameter type. For example, in:
template<typename T> void f() {
static const int n = 5;
typename T::template X<n> x;
}
... we don't know whether 'n' is dependent until we know whether the
corresponding template parameter is of type 'int' or 'const int&'.
Remove the OpenMP clause information from the OMPKinds.def file and use the
information from the new OMP.td file. There is now a single source of truth for the
directives and clauses.
To avoid generate lots of specific small code from tablegen, the macros previously
used in OMPKinds.def are generated almost as identical. This can be polished and
possibly removed in a further patch.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D92955
This allows ASTs to be merged when they contain GenericSelectionExpr
nodes (this is _Generic from C11). This is needed, for example, for
CTU analysis of C code that makes use of _Generic, like the Linux
kernel.
The node is already supported in the AST, but it didn't have a matcher
in ASTMatchers. So, this change adds the matcher and adds support to
ASTImporter. Additionally, this change adds support for structural
equivalence of _Generic in the AST.
Reviewed By: martong, aaron.ballman
Differential Revision: https://reviews.llvm.org/D92600
of type- and value-dependency.
A static data member initialized to a constant inside a class template
is no longer considered value-dependent, per DR1413. A const but not
constexpr variable of literal type (other than integer or enumeration)
is no longer considered value-dependent, per P1815R2.
This patch enables the Clang type __vector_pair and its associated LLVM
intrinsics even when MMA is disabled. With this patch, the type is now controlled
by the PPC paired-vector-memops option. The builtins and intrinsics will be
renamed to drop the mma prefix in another patch.
Differential Revision: https://reviews.llvm.org/D91819
For the Itanium ABI, this implements the mangling rule suggested in
https://github.com/itanium-cxx-abi/cxx-abi/issues/47, namely mangling
such template arguments as being cast to the parameter type in the case
where the template name is overloadable. This can cause a mangling
change for rare cases, where
* the template argument declaration is converted from its declared type
to the type of the template parameter, and
* the template parameter either has a deduced type or is a parameter of
a function template.
However, such changes are necessary to avoid mangling collisions. The
ABI changes can be reversed with -fclang-abi-compat=11 or earlier.
Re-commit with a fix for a couple of regressions.
Differential Revision: https://reviews.llvm.org/D91488
The import of a typedefs with an attribute uses clang::Decl::setAttrs().
But that needs the ASTContext which we can get only from the
TranslationUnitDecl. But we can get the TUDecl only thourgh the
DeclContext, which is not set by the time of the setAttrs call.
Fix: import the attributes only after the DC is surely imported.
Btw, having the attribute import initiated from GetImportedOrCreateDecl was
fundamentally flawed. Now that is implicitly fixed.
Differential Revision: https://reviews.llvm.org/D92962
For the Itanium ABI, this implements the mangling rule suggested in
https://github.com/itanium-cxx-abi/cxx-abi/issues/47, namely mangling
such template arguments as being cast to the parameter type in the case
where the template name is overloadable. This can cause a mangling
change for rare cases, where
* the template argument declaration is converted from its declared type
to the type of the template parameter, and
* the template parameter either has a deduced type or is a parameter of
a function template.
However, such changes are necessary to avoid mangling collisions. The
ABI changes can be reversed with -fclang-abi-compat=11 or earlier.
Re-commit with a fix for the regression introduced last time: don't
expect parameters and arguments to line up inside an <unresolved-name>
mangling.
Differential Revision: https://reviews.llvm.org/D91488
For the Itanium ABI, this implements the mangling rule suggested in
https://github.com/itanium-cxx-abi/cxx-abi/issues/47, namely mangling
such template arguments as being cast to the parameter type in the case
where the template name is overloadable. This can cause a mangling
change for rare cases, where
* the template argument declaration is converted from its declared type
to the type of the template parameter, and
* the template parameter either has a deduced type or is a parameter of
a function template.
However, such changes are necessary to avoid mangling collisions. The
ABI changes can be reversed with -fclang-abi-compat=11 or earlier.
Differential Revision: https://reviews.llvm.org/D91488
Remove the OpenMP clause information from the OMPKinds.def file and use the
information from the new OMP.td file. There is now a single source of truth for the
directives and clauses.
To avoid generate lots of specific small code from tablegen, the macros previously
used in OMPKinds.def are generated almost as identical. This can be polished and
possibly removed in a further patch.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D92955
When the evaluator encounters an error-dependent returnstmt, before this patch
it returned a ESR_Returned without setting the result, the callsides think this
is a successful execution, and try to access the Result which causes the crash.
The fix is to always return failed as we don't know the result of the
error-dependent return stmt.
Differential Revision: https://reviews.llvm.org/D92969
CXXDeductionGuideDecl with a local typedef has its own copy of the
TypedefDecl with the CXXDeductionGuideDecl as the DeclContext of that
TypedefDecl.
```
template <typename T> struct A {
typedef T U;
A(U, T);
};
A a{(int)0, (int)0};
```
Related discussion on cfe-dev:
http://lists.llvm.org/pipermail/cfe-dev/2020-November/067252.html
Without this fix, when we import the CXXDeductionGuideDecl (via
VisitFunctionDecl) then before creating the Decl we must import the
FunctionType. However, the first parameter's type is the afore mentioned
local typedef. So, we then start importing the TypedefDecl whose
DeclContext is the CXXDeductionGuideDecl itself. The infinite loop is
formed.
```
#0 clang::ASTNodeImporter::VisitCXXDeductionGuideDecl(clang::CXXDeductionGuideDecl*) clang/lib/AST/ASTImporter.cpp:3543:0
#1 clang::declvisitor::Base<std::add_pointer, clang::ASTNodeImporter, llvm::Expected<clang::Decl*> >::Visit(clang::Decl*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/DeclNodes.inc:405:0
#2 clang::ASTImporter::ImportImpl(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8038:0
#3 clang::ASTImporter::Import(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8200:0
#4 clang::ASTImporter::ImportContext(clang::DeclContext*) clang/lib/AST/ASTImporter.cpp:8297:0
#5 clang::ASTNodeImporter::ImportDeclContext(clang::Decl*, clang::DeclContext*&, clang::DeclContext*&) clang/lib/AST/ASTImporter.cpp:1852:0
#6 clang::ASTNodeImporter::ImportDeclParts(clang::NamedDecl*, clang::DeclContext*&, clang::DeclContext*&, clang::DeclarationName&, clang::NamedDecl*&, clang::SourceLocation&) clang/lib/AST/ASTImporter.cpp:1628:0
#7 clang::ASTNodeImporter::VisitTypedefNameDecl(clang::TypedefNameDecl*, bool) clang/lib/AST/ASTImporter.cpp:2419:0
#8 clang::ASTNodeImporter::VisitTypedefDecl(clang::TypedefDecl*) clang/lib/AST/ASTImporter.cpp:2500:0
#9 clang::declvisitor::Base<std::add_pointer, clang::ASTNodeImporter, llvm::Expected<clang::Decl*> >::Visit(clang::Decl*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/DeclNodes.inc:315:0
#10 clang::ASTImporter::ImportImpl(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8038:0
#11 clang::ASTImporter::Import(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8200:0
#12 llvm::Expected<clang::TypedefNameDecl*> clang::ASTNodeImporter::import<clang::TypedefNameDecl>(clang::TypedefNameDecl*) clang/lib/AST/ASTImporter.cpp:165:0
#13 clang::ASTNodeImporter::VisitTypedefType(clang::TypedefType const*) clang/lib/AST/ASTImporter.cpp:1304:0
#14 clang::TypeVisitor<clang::ASTNodeImporter, llvm::Expected<clang::QualType> >::Visit(clang::Type const*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/TypeNodes.inc:74:0
#15 clang::ASTImporter::Import(clang::QualType) clang/lib/AST/ASTImporter.cpp:8071:0
#16 llvm::Expected<clang::QualType> clang::ASTNodeImporter::import<clang::QualType>(clang::QualType const&) clang/lib/AST/ASTImporter.cpp:179:0
#17 clang::ASTNodeImporter::VisitFunctionProtoType(clang::FunctionProtoType const*) clang/lib/AST/ASTImporter.cpp:1244:0
#18 clang::TypeVisitor<clang::ASTNodeImporter, llvm::Expected<clang::QualType> >::Visit(clang::Type const*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/TypeNodes.inc:47:0
#19 clang::ASTImporter::Import(clang::QualType) clang/lib/AST/ASTImporter.cpp:8071:0
#20 llvm::Expected<clang::QualType> clang::ASTNodeImporter::import<clang::QualType>(clang::QualType const&) clang/lib/AST/ASTImporter.cpp:179:0
#21 clang::QualType clang::ASTNodeImporter::importChecked<clang::QualType>(llvm::Error&, clang::QualType const&) clang/lib/AST/ASTImporter.cpp:198:0
#22 clang::ASTNodeImporter::VisitFunctionDecl(clang::FunctionDecl*) clang/lib/AST/ASTImporter.cpp:3313:0
#23 clang::ASTNodeImporter::VisitCXXDeductionGuideDecl(clang::CXXDeductionGuideDecl*) clang/lib/AST/ASTImporter.cpp:3543:0
```
The fix is to first create the TypedefDecl and only then start to import
the DeclContext.
Basically, we could do this during the import of all other Decls (not
just for typedefs). But it seems, there is only one another AST
construct that has a similar cycle: a struct defined as a function
parameter:
```
int struct_in_proto(struct data_t{int a;int b;} *d);
```
In that case, however, we had decided to return simply with an error
back then because that seemed to be a very rare construct.
Differential Revision: https://reviews.llvm.org/D92209
This attribute permits a typedef to be associated with a class template
specialization as a preferred way of naming that class template
specialization. This permits us to specify that (for example) the
preferred way to express 'std::basic_string<char>' is as 'std::string'.
The attribute is applied to the various class templates in libc++ that have
corresponding well-known typedef names.
This is a re-commit. The previous commit was reverted because it exposed
a pre-existing bug that has since been fixed / worked around; see
PR48434.
Differential Revision: https://reviews.llvm.org/D91311
Ensure that we can deserialize a TypedefType even while in the middle of
deserializing its TypedefDecl, by removing the need to look at the
TypedefDecl while constructing the TypedefType.
This fixes all the currently-known failures for PR48434, but it's not a
complete fix, because we can still trigger deserialization cycles, which
are not supposed to happen.
This change exposed a pre-existing issue with deserialization cycles
caused by a combination of attributes and template instantiations
violating the deserialization ordering restrictions; see PR48434 for
details.
A previous commit attempted to work around PR48434, but appears to have
only been a partial fix, and fixing this properly seems non-trivial.
Backing out for now to unblock things.
This reverts commit 98f76adf4e and
commit a64c26a47a.
This is really just a workaround for a more fundamental issue in the way
we deserialize attributes. See PR48434 for details.
Also fix tablegen code generator to produce more correct indentation to
resolve buildbot issues with -Werror=misleading-indentation firing
inside the generated code.
_Nullable_result generally like _Nullable, except when being imported into a
swift async method. rdar://70106409
Differential revision: https://reviews.llvm.org/D92495
This attribute permits a typedef to be associated with a class template
specialization as a preferred way of naming that class template
specialization. This permits us to specify that (for example) the
preferred way to express 'std::basic_string<char>' is as 'std::string'.
The attribute is applied to the various class templates in libc++ that have
corresponding well-known typedef names.
Differential Revision: https://reviews.llvm.org/D91311
Migrate `ASTImporter::Import` over to using the `FileEntryRef` overload
of `SourceManager::createFileID`. No functionality change here.
Differential Revision: https://reviews.llvm.org/D92529
Update all the users of `AlignedCharArrayUnion` to stop peeking inside
(to look at `buffer`) so that a follow-up patch can replace it with an
alias to `std::aligned_union_t`.
This was reviewed as part of https://reviews.llvm.org/D92512, but I'm
splitting this bit out to commit first to reduce churn in case the
change to `AlignedCharArrayUnion` needs to be reverted for some
unexpected reason.
shouldRTTIBeUnique() returns false for iOS64CXXABI, which causes
RTTI objects to be emitted hidden. Update two tests that didn't
expect this to happen for the default triple.
Also rename iOS64CXXABI to AppleARM64CXXABI, since it's used for
arm64-apple-macos triples too.
Part of PR46644.
Differential Revision: https://reviews.llvm.org/D91904
caller.
This function did not satisfy its documented contract: it only
considered the first lookup result on each base path, not all lookup
results. It also performed unnecessary memory allocations.
This change results in a minor change to our representation: we now
include overridden methods that are found by any derived-to-base path
(not involving another override) in the list of overridden methods for a
function, rather than filtering out functions from bases that are both
direct virtual bases and indirect virtual bases for which the indirect
virtual base path contains another override for the function. (That
filtering rule is part of the class-scope name lookup rules, and doesn't
really have much to do with enumerating overridden methods.) The users
of the list of overridden methods do not appear to rely on this
filtering having happened, and it's simpler to not do it.
CXXDeductionGuideDecl is a FunctionDecl, but its constructor should be called
appropriately, at least to set the kind variable properly.
Differential Revision: https://reviews.llvm.org/D92109
The test case isn't using the AST matchers for all checks as there doesn't seem to be support for
matching NonTypeTemplateParmDecl default arguments. Otherwise this is simply importing the
default arguments.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D92106
The test case isn't using the AST matchers for all checks as there doesn't seem to be support for
matching TemplateTypeParmDecl default arguments. Otherwise this is simply importing the
default arguments.
Also updates several LLDB tests that now as intended omit the default template
arguments of several std templates.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D92103
Same idea as in D92103 and D92106, but I realised after creating those reviews that there are
also TemplateTemplateParmDecls that can have default arguments, so here's hopefully the
last patch for default template arguments.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D92119
This is partly in preparation for an upcoming change that can change the
order in which DeclContext lookup results are presented.
In passing, fix some obvious errors where name lookup's notion of a
"static member function" missed static member function templates, and
where its notion of "same set of declarations" was confused by the same
declarations appearing in a different order.
Previously we only considered using a substitution for a template-name
after already having mangled its prefix, so we'd produce nonsense
manglings like NS3_S4_IiEE where we should simply produce NS4_IiEE.
This is not ABI-compatible with previous Clang versions, and the old
behavior is restored by -fclang-abi-compat=11.0 or earlier.
When importing a `ClassTemplateSpecializationDecl` definition into a TU with a matching
`ClassTemplateSpecializationDecl` definition and a more recent forward decl, the ASTImporter
currently will call `MapImported()` for the definitions, but will return the forward declaration
from the `ASTImporter::Import()` call.
This is triggering some assertions in LLDB when we try to fully import some DeclContexts
before we delete the 'From' AST. The returned 'To' Decl before this patch is just the most recent
forward decl but that's not the Decl with the definition to which the ASTImporter will import
the child declarations.
This patch just changes that the ASTImporter returns the definition that the imported Decl was
merged with instead of the found forward declaration.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D92016
Previously, lax conversions were only allowed between SVE vector-length
agnostic types and vector-length specific types. This meant that code
such as the following:
#include <arm_sve.h>
#define N __ARM_FEATURE_SVE_BITS
#define FIXED_ATTR __attribute__ ((vector_size (N/8)))
typedef float fixed_float32_t FIXED_ATTR;
void foo() {
fixed_float32_t fs32;
svfloat64_t s64;
fs32 = s64;
}
was not allowed.
This patch makes a minor change to areLaxCompatibleSveTypes to allow for
lax conversions to be performed between SVE vector-length agnostic types
and GNU vectors.
Differential Revision: https://reviews.llvm.org/D91696
wchar_t can be signed (thus hasSignedIntegerRepresentation() returns
true), but it doesn't have an unsigned type, which would lead to a crash
when trying to get it.
With this fix, we special-case WideChar types in the pointer assignment
code.
Differential Revision: https://reviews.llvm.org/D91625
For MASM syntax, the prefixes are not enclosed in braces.
The assembly code should like:
"evex vcvtps2pd xmm0, xmm1"
Differential Revision: https://reviews.llvm.org/D90441
Fix a crash when evaluating a constexpr function which contains
recovery-exprs. https://bugs.llvm.org/show_bug.cgi?id=46837
Would be nice to have constant expression evaluator support general template
value-dependent expressions, but it requires more work.
This patch is a good start I think, to handle the error-only
value-dependent expressions.
Differential Revision: https://reviews.llvm.org/D84637
Lax vector conversions was behaving incorrectly for implicit casts
between scalable and fixed-length vector types. For example, this:
#include <arm_sve.h>
#define N __ARM_FEATURE_SVE_BITS
#define FIXED_ATTR __attribute__((arm_sve_vector_bits(N)))
typedef svfloat32_t fixed_float32_t FIXED_ATTR;
void allowed_depending() {
fixed_float32_t fs32;
svfloat64_t s64;
fs32 = s64;
}
... would fail because the vectors have differing lane sizes. This patch
implements the correct behaviour for
-flax-vector-conversions={none,all,integer}. Specifically:
- -flax-vector-conversions=none prevents all lax vector conversions
between scalable and fixed-sized vectors.
- -flax-vector-conversions=integer allows lax vector conversions between
scalable and fixed-size vectors whose element types are integers.
- -flax-vector-conversions=all allows all lax vector conversions between
scalable and fixed-size vectors (including those with floating point
element types).
The implicit conversions are implemented as bitcasts.
Reviewed By: fpetrogalli
Differential Revision: https://reviews.llvm.org/D91067
Just skip (non-bitfield) zero-sized fields, like we do with empty bases.
The class->struct conversion in the test is because -std=c++20 else deletes some default methods
due to non-accessible base dtors otherwise.
As a side-effect of writing the test, I discovered that D76801 did an ABI breaking change of sorts
for Objective-C's @encode. But it's been in for a while, so I'm not sure if we want to row back on
that or now.
Fixes PR48048.
Differential Revision: https://reviews.llvm.org/D90622
except where they are necessary to disambiguate the target.
This substantially improves diagnostics from the standard library,
which are otherwise full of `::__1::` noise.
arguments of types by default.
This somewhat improves the worst-case printing of types like
std::string, std::vector, etc., where many irrelevant default arguments
can be included in the type as printed if we've lost the type sugar.
The Itanium CXX ABI grammer has been extended to support parameterized
vendor extended types [1].
This patch updates Clang's mangling for matrix types to use the new
extension.
[1] b359d28971
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D91253
mangling support for non-type template parameters of class type and
template parameter objects.
The Itanium side of this follows the approach I proposed in
https://github.com/itanium-cxx-abi/cxx-abi/issues/47 on 2020-09-06.
The MSVC side of this was determined empirically by observing MSVC's
output.
Differential Revision: https://reviews.llvm.org/D89998
Add MMA builtin decoding. These builtins use the new PowerPC-specific types __vector_pair and __vector_quad.
So to avoid pervasive changes, we use custom type descriptors and custom decoding for these builtins.
We also use custom code generation to expand builtin calls with pointers to simpler intrinsic calls with non-pointer types.
Differential Revision: https://reviews.llvm.org/D81748
Summary:
IgnoreUnlessSpelledInSource mode should ignore these because they are
not written in the source. This matters for example when trying to
replace types or values which are templated. The new test in
TransformerTest.cpp in this commit demonstrates the problem.
In existing matcher code, users can write
`unless(isInTemplateInstantiation())` or `unless(isInstantiated())` (the
user must know which to use). The point of the
TK_IgnoreUnlessSpelledInSource mode is to allow the novice to avoid such
details. This patch changes the IgnoreUnlessSpelledInSource mode to
skip over implicit template instantiations.
This patch does not change the TK_AsIs mode.
Note: An obvious attempt at an alternative implementation would simply
change the shouldVisitTemplateInstantiations() in ASTMatchFinder.cpp to
return something conditional on the operational TraversalKind. That
does not work because shouldVisitTemplateInstantiations() is called
before a possible top-level traverse() matcher changes the operational
TraversalKind.
Reviewers: sammccall, aaron.ballman, gribozavr2, ymandel, klimek
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80961
The attribute has no effect on a do statement since the path of execution
will always include its substatement.
It adds a diagnostic when the attribute is used on an infinite while loop
since the codegen omits the branch here. Since the likelihood attributes
have no effect on a do statement no diagnostic will be issued for
do [[unlikely]] {...} while(0);
Differential Revision: https://reviews.llvm.org/D89899
friends.
When determining whether a function has a template instantiation
pattern, look for other declarations of that function that were
instantiated from a friend function definition, rather than assuming
that checking for member specialization information on whichever
declaration name lookup found will be sufficient.
This patch adds tests and support for operations on SVE vectors created
by the 'arm_sve_vector_bits' attribute, described by the Arm C Language
Extensions (ACLE, version 00bet6, section 3.7.3.3) for SVE [1].
This covers the following:
* VLSTs support the same forms of element-wise initialization as GNU
vectors.
* VLSTs support the same built-in C and C++ operators as GNU vectors.
* Conditional and binary expressions containing GNU and SVE vectors
(fixed or sizeless) are invalid since the ambiguity around the result
type affects the ABI.
No functional changes were required to support vector initialization and
operators. The functional changes are to address unsupported conditional and
binary expressions.
[1] https://developer.arm.com/documentation/100987/latest
Reviewed By: fpetrogalli
Differential Revision: https://reviews.llvm.org/D88233
As mentioned in the defect, the lambda static invoker does not follow
the calling convention of the lambda itself, which seems wrong. This
patch ensures that the calling convention of operator() is passed onto
the invoker and conversion-operator type.
This is accomplished by extracting the calling-convention determination
code out into a separate function in order to better reflect the 'thiscall'
work, as well as somewhat better support the future implementation of
https://devblogs.microsoft.com/oldnewthing/20150220-00/?p=44623
For any target (basically just win32) that has a different free and
static function calling convention, this generates BOTH alternatives.
This required some work to get the Windows mangler to work correctly for
this, as well as some tie-breaking for the unary operators.
Differential Revision: https://reviews.llvm.org/D89559
Summary:
Skip over elidable nodes, and ensure that intermediate
CXXFunctionalCastExpr nodes are also skipped if they are semantic.
Reviewers: klimek, ymandel
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D82278
Checks to make sure that stdlib's (std::)free is being appropriately
used. Presently checks for the following misuses:
- free(&stack_object)
- free(stack_array)
Differential Revision: https://reviews.llvm.org/D89988
Define the __vector_pair and __vector_quad types that are used to manipulate
the new accumulator registers introduced by MMA on PowerPC. Because these two
types are specific to PowerPC, they are defined in a separate new file so it
will be easier to add other PowerPC specific types if we need to in the future.
Differential Revision: https://reviews.llvm.org/D81508
The local variable CmpResult added in that change shadowed the
type CmpResult, which confused an older gcc. Rename the variable
CmpResult to APFloatCmpResult.
It turns out that `FileInfo` *always* has a ContentCache. Clarify that
in the code:
- Update the private version of `SourceManager::createFileID` to take a
`ContentCache&` instead of `ContentCache*`, and rename it to
`createFileIDImpl` for clarity.
- Change `FileInfo::getContentCache` to return a reference.
Differential Revision: https://reviews.llvm.org/D89554
This requires that we track enough information to determine the original
type of the parameter in a substituted non-type template parameter, to
distinguish the reference-to-class case from the class case.
non-type template parameters.
Create a unique TemplateParamObjectDecl instance for each such value,
representing the globally unique template parameter object to which the
template parameter refers.
No IR generation support yet; that will follow in a separate patch.
Changes:
- initializer expressions of constexpr variable are now wraped in a ConstantExpr. this is mainly used for testing purposes. the old caching system has not yet been removed.
- Add all the missing Serialization and Importing for APValue.
- Improve dumping of APValue when ASTContext isn't available.
- Cleanup leftover from last patch.
- Add Tests for Import and serialization.
Differential Revision: https://reviews.llvm.org/D63640
Permitting non-standards-driven "do the best you can" constant-folding
of array bounds is permitted solely as a GNU compatibility feature. We
should not be doing it in any language mode that is attempting to be
conforming.
From https://reviews.llvm.org/D20090 it appears the intent here was to
permit `__constant int` globals to be used in array bounds, but the
change in that patch only added half of the functionality necessary to
support that in the constant evaluator. This patch adds the other half
of the functionality and turns off constant folding for array bounds in
OpenCL.
I couldn't find any spec justification for accepting the kinds of cases
that D20090 accepts, so a reference to where in the OpenCL specification
this is permitted would be useful.
Note that this change also affects the code generation in one test:
because after 'const int n = 0' we now treat 'n' as a constant
expression with value 0, it's now a null pointer, so '(local int *)n'
forms a null pointer rather than a zero pointer.
Reviewed By: Anastasia
Differential Revision: https://reviews.llvm.org/D89520
This fixes miscomputation of __builtin_constant_evaluated in the
initializer of a variable that's not usable in constant expressions, but
is readable when constant-folding.
If evaluation of a constant initializer fails, we throw away the
evaluated result instead of keeping it as a non-constant-initializer
value for the variable, because it might not be a correct value.
To avoid regressions for initializers that are foldable but not formally
constant initializers, we now try constant-evaluating some globals in
C++ twice: once to check for a constant initializer (in an mode where
is_constannt_evaluated returns true) and again to determine the runtime
value if the initializer is not a constant initializer.
Instead of framing the interface around whether the variable is an ICE
(which is only interesting in C++98), primarily track whether the
initializer is a constant initializer (which is interesting in all C++
language modes).
No functionality change intended.
for which it matters.
This is a step towards separating checking for a constant initializer
(in which std::is_constant_evaluated returns true) and any other
evaluation of a variable initializer (in which it returns false).
PartialDiagnostic misses some functions compared to DiagnosticBuilder.
This patch refactors DiagnosticBuilder and PartialDiagnostic, extracts
the common functionality so that the streaming << operators are
shared.
Differential Revision: https://reviews.llvm.org/D84362
This implements the likelihood attribute for the switch statement. Based on the
discussion in D85091 and D86559 it only handles the attribute when placed on
the case labels or the default labels.
It also marks the likelihood attribute as feature complete. There are more QoI
patches in the pipeline.
Differential Revision: https://reviews.llvm.org/D89210
This addresses a regression where pretty much all C++ compilations using
-frounding-math now fail, due to rounding being performed in constexpr
function definitions in the standard library.
This follows the "manifestly constant evaluated" approach described in
https://reviews.llvm.org/D87528#2270676 -- evaluations that are required
to succeed at compile time are permitted even in regions with dynamic
rounding modes, as are (unfortunately) the evaluation of the
initializers of local variables of const integral types.
Differential Revision: https://reviews.llvm.org/D89360
This reverts commits 683b308c07 and
8487bfd4e9.
We will go for a more restricted approach that does not give freedom to
everyone to change ABIs on whichever platform.
See the discussion on https://reviews.llvm.org/D85802.
Capitalize the profile function of APValue such that it can be used by FoldingSetNodeID
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D88643
callee in constant evaluation.
We previously made a deep copy of function parameters of class type when
passing them, resulting in the destructor for the parameter applying to
the original argument value, ignoring any modifications made in the
function body. This also meant that the 'this' pointer of the function
parameter could be observed changing between the caller and the callee.
This change completely reimplements how we model function parameters
during constant evaluation. We now model them roughly as if they were
variables living in the caller, albeit with an artificially reduced
scope that covers only the duration of the function call, instead of
modeling them as temporaries in the caller that we partially "reparent"
into the callee at the point of the call. This brings some minor
diagnostic improvements, as well as significantly reduced stack usage
during constant evaluation.
Remove `ContentCache::getBuffer`, which always returned a
dereferenceable `MemoryBuffer*` and had a `bool*Invalid` out parameter,
and replace it with:
- `ContentCache::getBufferOrNone`, which returns
`Optional<MemoryBufferRef>`. This is the new API that consumers should
use. Later it could be renamed to `getBuffer`, but intentionally using
a different name to root out any unexpected callers.
- `ContentCache::getBufferPointer`, which returns `MemoryBuffer*` with
"optional" semantics. This is `private` to avoid growing callers and
`SourceManager` has temporarily been made a `friend` to access it.
Later paches will update the transitive callers to not need a raw
pointer, and eventually this will be deleted.
No functionality change intended here.
Differential Revision: https://reviews.llvm.org/D89348
This implements the flag proposed in RFC http://lists.llvm.org/pipermail/cfe-dev/2020-August/066437.html.
The goal is to add a way to override the default target C++ ABI through
a compiler flag. This makes it easier to test and transition between different
C++ ABIs through compile flags rather than build flags.
In this patch:
- Store `-fc++-abi=` in a LangOpt. This isn't stored in a
CodeGenOpt because there are instances outside of codegen where Clang
needs to know what the ABI is (particularly through
ASTContext::createCXXABI), and we should be able to override the
target default if the flag is provided at that point.
- Expose the existing ABIs in TargetCXXABI as values that can be passed
through this flag.
- Create a .def file for these ABIs to make it easier to check flag
values.
- Add an error for diagnosing bad ABI flag values.
Differential Revision: https://reviews.llvm.org/D85802
During the import of attributes we forgot to set the spelling list
index. This caused a segfault when we wanted to traverse the AST
(e.g. by the dump() method).
Differential Revision: https://reviews.llvm.org/D89318
During the import of FormatAttrs we forgot to import the type (e.g
`__scanf__`) of the attribute. This caused a segfault when we wanted to
traverse the AST (e.g. by the dump() method).
Differential Revision: https://reviews.llvm.org/D89319
Instead of collecting all specializations and doing a post-filterin, we
can just get all targeted specializations from getPartialSpecializationsizations.
Differential Revision: https://reviews.llvm.org/D89220
Balázs Kéri