dependent on f109b10
Given
f109b10168 (commitcomment-113477829),
we need to revert f109b10. So it will be better to make this patch not
dependent on f109b10 as much as possible.
even if its initializer has side effects
Close https://github.com/llvm/llvm-project/issues/61892
The variables whose initializer has side effects will be emitted even if
it is not used. But it shouldn't be true after we introduced modules.
The variables in other modules shouldn't be emitted if it is not used
even if its initializer has size effects.
Also this patch rename `Decl::isInCurrentModuleUnit` to
`Decl::isInAnotherModuleUnit` to make it closer to the semantics.
Decl::isInCurrentModuleUnit
Refactor `Sema::isModuleUnitOfCurrentTU` to `Decl::isInCurrentModuleUnit`
to make code simpler a little bit. Note that although this patch
introduces a FIXME, this is an existing issue and this patch just tries
to describe it explicitly.
Reported by Coverity:
In clang::ASTContext::hasUniqueObjectRepresentations(clang::QualType, bool): Return value of function which returns null is dereferenced without checking.
(Ty->isMemberPointerType()) {
//returned_null: getAs returns nullptr.
//var_assigned: Assigning: MPT = nullptr return value from getAs.
const auto *MPT = Ty->getAs<MemberPointerType>();
//dereference: Dereferencing a pointer that might be nullptr MPT when calling getMemberPointerInfo. (The virtual call resolves to
<unnamed>::ItaniumCXXABI::getMemberPointerInfo.)
return !ABI->getMemberPointerInfo(MPT).HasPadding;
}
ABIs assume the parameter passed to `getMemberPointerInfo` is non-null.
This patch checks type by doing a `if (const auto *MPT = Ty->getAs<MemberPointerType>())` instead.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D149922
RISCVTargetParser.h has a dependency on a tablegen generated file.
Using RISCVISAInfo.h instead avoids this dependency.
We just need this constant somewhere visible to the frontend and
backend and I'm trying to avoid adding a header just for it.
This allows the user to set the size of the scalable vector so they
can be used in structs and as the type of global variables. This works
by representing the type as a fixed vector instead of a scalable vector
in IR. Conversions to and from scalable vectors are made where necessary
like function arguments/returns and intrinsics.
This features has been requested here
https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/176
I know arm_sve_vector_bits is used by the Eigen library so this
could be used to port Eigen to RVV.
This patch adds a new preprocessor define `__riscv_v_fixed_vlen` that
is set when -mrvv_vector_bits is passed on the command line.
The code is largely based on the AArch64 code. A lot of code was
copy/pasted and then modiied to RVV. There may be some opportunities
for sharing.
This first patch only supports the LMUL=1 types. Additional changes
will be needed to support other LMULs. I have also not supported
mask vectors.
Differential Revision: https://reviews.llvm.org/D145088
We only need the list of constriant template arguments when we have a
valid constraint. We give up on merging the auto-type constraints if
the template arguments don't match, but neglected to clear the
collection of template arguments. The result was we had an AutoType
where we initialized the number of template arguments, but never
initialized the template arguments themselves.
This patch adds an assert to catch this in the future, plus ensures we
clear out the vector so we don't try to create the AutoType incorrectly.
Reported by Coverity:
AUTO_CAUSES_COPY
Unnecessary object copies can affect performance.
1. Inside "SemaDeclCXX.cpp" file, in <unnamed>::DiagnoseUninitializedFields(clang::Sema &, clang::CXXConstructorDecl const *): Using the auto keyword without an & causes the copy of an object of type CXXBaseSpecifier.
2. Inside "ClangAttrEmitter.cpp" file, in clang::EmitClangAttrParsedAttrImpl(llvm::RecordKeeper &, llvm::raw_ostream &): Using the auto keyword without an & causes the copy of an object of type pair.
3. Inside "Marshallers.h" file, in clang::ast_matchers::dynamic::internal::MapAnyOfBuilderDescriptor::buildMatcherCtor(clang::ast_matchers::dynamic::SourceRange, llvm::ArrayRef<clang::ast_matchers::dynamic::ParserValue>, clang::ast_matchers::dynamic::Diagnostics *): Using the auto keyword without an & causes the copy of an object of type ParserValue.
4. Inside "CGVTables.cpp" file, in clang::CodeGen::CodeGenModule::GetVCallVisibilityLevel(clang::CXXRecordDecl const *, llvm::DenseSet<clang::CXXRecordDecl const *, llvm::DenseMapInfo<clang::CXXRecordDecl const *, void>> &): Using the auto keyword without an & causes the copy of an object of type CXXBaseSpecifier.
5. Inside "ASTContext.cpp" file, in hasTemplateSpecializationInEncodedString(clang::Type const *, bool): Using the auto keyword without an & causes the copy of an object of type CXXBaseSpecifier.
6. Inside "ComputeDependence.cpp" file, in clang::computeDependence(clang::DependentScopeDeclRefExpr *): Using the auto keyword without an & causes the copy of an object of type TemplateArgumentLoc.
Reviewed By: tahonermann, erichkeane
Differential Revision: https://reviews.llvm.org/D148812
This patch adds a new trait to allow standard libraries to forward `std::equal` calls to `memcmp` in more cases.
Reviewed By: aaron.ballman
Spies: Mordante, shafik, xbolva00, libcxx-commits, cfe-commits, ldionne
Differential Revision: https://reviews.llvm.org/D147175
An assertion in Qualifiers::addObjCLifetime fails when the ObjC lifetime
bits are already set.
Instead of calling operator+=, call addConsistentQualifiers, which
allows the lifetime bits to be set again as long the new value doesn't
conflict with the old value.
This fixes https://github.com/llvm/llvm-project/issues/61419.
Differential Revision: https://reviews.llvm.org/D147263
This change reverts the functional change from D144626 but retains its
test. Instead of dealing with the possibility that a trailing requires
clause might have been rewritten into some other incorrect form, just
stop rewriting it.
No functionality changes intended.
Reviewed By: erichkeane, ChuanqiXu
Differential Revision: https://reviews.llvm.org/D147281
This is necessary in order for type equality checking, for example
across redeclarations, to require constraints to match. This is also a
prerequisite for including the constraints in manglings.
In passing, fix a bug where TemplateArgument::Profile would produce the
same profile for two structurally different template names, which caused
this change to re-expose the crash previously addressed by D133072,
which it turns out had not quite addressed all problematic cases.
This follows C++ [temp.over.link]/6, which says that constraints are not
part of what determines whether two template parameters are equivalent.
This allows templates that have different constraints on nested template
template parameters to be ordered by their constraints.
constrained friend".
When a friend declaration has a requires-clause, and either it's a
non-template function or it's a function template whose requires-clause
depends on an enclosing template parameter, it is member-like for the
purpose of redeclaration checking. Specifically, the lexically enclosing
class becomes part of its signature, so it can only be redeclared by
another declaration within the same class. In this change, we call such
functions "member-like constrained friends".
No functional change intended.
Previously, distinct lambdas would get merged, and multiple definitions
of the same lambda would not get merged, because we attempted to
identify lambdas by their ordinal position within their lexical
DeclContext. This failed for lambdas within namespace-scope variables
and within variable templates, where the lexical position in the context
containing the variable didn't uniquely identify the lambda.
In this patch, we instead identify lambda closure types by index within
their context declaration, which does uniquely identify them in a way
that's consistent across modules.
This change causes a deserialization cycle between the type of a
variable with deduced type and a lambda appearing as the initializer of
the variable -- reading the variable's type requires reading and merging
the lambda, and reading the lambda requires reading and merging the
variable. This is addressed by deferring loading the deduced type of a
variable until after we finish recursive deserialization.
This also exposes a pre-existing subtle issue where loading a
variable declaration would trigger immediate loading of its initializer,
which could recursively refer back to properties of the variable. This
particularly causes problems if the initializer contains a
lambda-expression, but can be problematic in general. That is addressed
by switching to lazily loading the initializers of variables rather than
always loading them with the variable declaration. As well as fixing a
deserialization cycle, that should improve laziness of deserialization
in general.
LambdaDefinitionData had 63 spare bits in it, presumably caused by an
off-by-one-error in some previous change. This change claims 32 of those bits
as a counter for the lambda within its context. We could probably move the
numbering to separate storage, like we do for the device-side mangling number,
to optimize the likely-common case where all three numbers (host-side mangling
number, device-side mangling number, and index within the context declaration)
are zero, but that's not done in this change.
Fixes#60985.
Reviewed By: #clang-language-wg, aaron.ballman
Differential Revision: https://reviews.llvm.org/D145737
circumstances when parsing ASTs
Fix ArgsAsWritten being null for ConceptSpecializationExpr in certain
circumstances when parsing ASTs
ASTStmtWriter::VisitConceptSpecializationExpr specifically expects
getTemplateArgsAsWritten() to return true, which it wasn't when parsed
by ASTContext.cpp in certain edge cases.
Fixes: #61486
Differential Revision: https://reviews.llvm.org/D146678
This patch adds the builtin type __SVCount_t to Clang, which is an opaque
scalable type defined in the SME2 C and C++ Language Extensions.
The type maps to the `target("aarch64.svcount")` LLVM IR type.
Reviewed By: paulwalker-arm
Differential Revision: https://reviews.llvm.org/D136864
definition correctly
Close https://github.com/llvm/llvm-project/issues/61067
Previously we will only handle the defaulted member functions as
discardable ODR. But we need to handle defaulted friend function in this
way too. Otherwise we may run into the problems the above issue report
mentions.
Close https://github.com/llvm/llvm-project/issues/60890.
For the following example:
```
export module a;
export template<typename T>
struct a {
friend void aa(a) requires(true) {
}
};
```
```
export module b;
import a;
struct b {
a<int> m;
};
```
```
export module c;
import a;
struct c {
void f() const {
aa(a<int>());
}
};
```
```
import a;
import b;
import c;
void d() {
aa(a<int>());
}
```
The current clang will reject this incorrectly. The reason is that the
require clause will be replaced with the evaluated version
(efae3174f0/clang/lib/Sema/SemaConcept.cpp (L664-L665)).
In module 'b', the friend function is instantiated but not used so the
require clause of the friend function is `(true)`. However, in module
'c', the friend function is used so the require clause is `true`. So
deserializer classify these two function to two different functions
instead of one. Then here is the bug report.
The proposed solution is to try to compare the trailing require clause
of the primary template when performing ODR checking.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D144626
Close https://github.com/llvm/llvm-project/issues/60890.
For the following example:
```
export module a;
export template<typename T>
struct a {
friend void aa(a) requires(true) {
}
};
```
```
export module b;
import a;
struct b {
a<int> m;
};
```
```
export module c;
import a;
struct c {
void f() const {
aa(a<int>());
}
};
```
```
import a;
import b;
import c;
void d() {
aa(a<int>());
}
```
The current clang will reject this incorrectly. The reason is that the
require clause will be replaced with the evaluated version
(efae3174f0/clang/lib/Sema/SemaConcept.cpp (L664-L665)).
In module 'b', the friend function is instantiated but not used so the
require clause of the friend function is `(true)`. However, in module
'c', the friend function is used so the require clause is `true`. So
deserializer classify these two function to two different functions
instead of one. Then here is the bug report.
The proposed solution is to try to compare the trailing require clause
of the primary template when performing ODR checking.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D144626
These 2 spots are protecting calls to SVE specific functions. If RISC-V
sizeless types end up in there we trigger assertions.
Use the more specific isSVESizelessBuiltinType() to avoid letting
RISC-V vectors through.
Reviewed By: asb, c-rhodes
Differential Revision: https://reviews.llvm.org/D144772
[temp.friend]p9 says
> Such a constrained friend function or function template declaration does
not declare the same function or function template as a declaration in
any other scope.
But the friend declaration in the same scope shouldn't fall into this
catagory. Although the logic is handled in 'FriendsDifferByConstraints',
the compiler may haven't merged the lexcial declcontext in time.
Also the code removed is not covered by test too.
Let's handle the logic in sema as we've done now.
ASTContext::getRawCommentForDeclNoCacheImpl in this case, extracts the text between
the comment and declaration to make sure if there are no other declarations or preprocessor
directives between comment or declarations.
While using Text.find_first_of or Text.find_last_of is functionally the same,
using Text.find_last_of terminates fast in the presence of such.
Especially in generated code with sparse comments, it takes longer
to bailout when there is code in-between. Searching from last
(with find_last_of) bails out faster.
This shows up in perf profiles with clangd in some auto-generated code.
ASTContext::getRawCommentForDeclNoCacheImpl showing as much as 18.2% in this
case. With find_last_of, this drops to 2.8%.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D141950
Avoids warnings in -asserts builds.
ASTContext.cpp:4098:1: error: non-void function does not return a value in all control paths [-Werror,-Wreturn-type]
}
^
This patch introduces a new type __externref_t that denotes a WebAssembly opaque
reference type. It also implements builtin __builtin_wasm_ref_null_extern(),
that returns a null value of __externref_t. This lays the ground work
for further builtins and reference types.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D122215
Close https://github.com/llvm/llvm-project/issues/60693.
In this issue, we can find that the importer will try to generate the
template specialization again in the importer, which is not good and
wastes time. This patch tries to address the problem.
Currently default simd alignment is defined by Clang specific TargetInfo class.
This class cannot be reused for LLVM Flang. That's why default simd alignment
calculation has been moved to OMPIRBuilder which is common for Flang and Clang.
Previous attempt: https://reviews.llvm.org/D138496 was wrong because
the default alignment depended on the number of built LLVM targets.
If we wanted to calculate the default alignment for PPC and we hadn't specified
PPC LLVM target to build, then we would get 0 as the alignment because
OMPIRBuilder couldn't create PPCTargetMachine object and it returned 0 as
the default value.
If PPC LLVM target had been built earlier, then OMPIRBuilder could have created
PPCTargetMachine object and it would have returned 128.
Differential Revision: https://reviews.llvm.org/D141910
Reviewed By: jdoerfert
This patch introduces a new type __externref_t that denotes a WebAssembly opaque
reference type. It also implements builtin __builtin_wasm_ref_null_extern(),
that returns a null value of __externref_t. This lays the ground work
for further builtins and reference types.
Differential Revision: https://reviews.llvm.org/D122215
**Summary**
This patch adds a `IsDefaulted` field to `clang::TemplateArgument`.
To prevent memory footprint increase we still 1 bit from `ArgKind`.
**Changes**
1. `getIsDefaulted`/`setIsDefaulted` to allow clients to communicate
an argument's defaulted-ness to the TypePrinter
2. The `TemplateArgument` properties description had to be changed
to make sure we correctly mark the defaulted-ness of arguments
that came from a deserialized AST (caught by the HLSL test-suite)
3. The `TemplateArgument` constructors now accept a `IsDefaulted`
parameter to simplify construction from the tablegen description.
Though if people don't want to clutter the constructors we can
instead call `setIsDefaulted` from tablegen
4. When `clang::Sema` checks the template arguments against template
parameters we now call `setIsDefaulted`. This makes sure that
whenever a specialization decl gets constructed, the defaulted-ness
of the associated `TemplateArgument`s has already been deduced.
This preserves the immutability of `TemplateArgumentList`s
**Background**
In LLDB we construct ASTs from debug-info and hand it to clang
to perform actions such as printing/formatting a typenames.
Some debug formats, specifically DWARF, may only encode information
about class template instantiations, losing the structure of the generic
class definition. However, the `clang::TypePrinter` needs a properly
constructed `ClassTemplateDecl` with generic default argument decls
to be able to deduce whether a `ClassTemplateSpecializationDecl` was
instantiatiated with `TemplateArgument`s that correspond to the
defaults. LLDB does know whether a particular template argument was
defaulted, but can't currently tell clang about it.
This patch allows LLDB to set the defaulted-ness of a `TemplateArgument`
and thus benefit more from `clang::TypePrinter`.
See discussion in https://reviews.llvm.org/D140423
**Testing**
* Added unit-test
* LLDB/clang/llvm test-suite passes
Differential Revision: https://reviews.llvm.org/D141826
Currently default simd alignment is defined by Clang specific TargetInfo class.
This class cannot be reused for LLVM Flang. That's why default simd alignment
calculation has been moved to OMPIRBuilder which is common for Flang and Clang.
Previous attempt: https://reviews.llvm.org/D138496 was wrong because
the default alignment depended on the number of built LLVM targets.
If we wanted to calculate the default alignment for PPC and we hadn't specified
PPC LLVM target to build, then we would get 0 as the alignment because
OMPIRBuilder couldn't create PPCTargetMachine object and it returned 0 as
the default value.
If PPC LLVM target had been built earlier, then OMPIRBuilder could have created
PPCTargetMachine object and it would have returned 128.
Differential Revision: https://reviews.llvm.org/D141910
Reviewed By: jdoerfert
The key part of getRawCommentForDecl() required to find a comment
is determining where to look for it. The location of the decl
itself is usually right, except when macros get involved. The
comment in the macro is stored in RawCommentList at the spelling
location of the decl, not at the place where the decl comes into
being as the macro is instantiated.
getDeclLocForCommentSearch() already contained to branches to try
handle comments inside macros, and we are able to replace them
and handle more cases as well, by returning the spelling location
of the decl's begin location. That is:
SourceMgr.getSpellingLoc(D->getBeginLoc())
Reviewed By: gribozavr2
Differential Revision: https://reviews.llvm.org/D142560
