The lifetimes of local variables and function parameters must end before
the call to a [[clang::musttail]] function, instead of before the
return, because we will not have a stack frame to hold them when doing
the call.
This documents this limitation, and adds diagnostics to warn about some
code which is invalid because of it.
This implements the logic of the `common_type` base template as a
builtin alias. If there should be no `type` member, an empty class is
returned. Otherwise a specialization of a `type_identity`-like class is
returned. The base template (i.e. `std::common_type`) as well as the
empty class and `type_identity`-like struct are given as arguments to
the builtin.
While working on supporting PR #109101 on Linux/sparc64, I was reminded
that `clang -m32` still defaults to generating V8 code, although the
64-bit kernel requires a V9 CPU.
This patch corrects that.
Tested on `sparc64-unknown-linux-gnu`, `x86_64-pc-linux-gnu`,
`sparcv9-sun-solaris2.11`, and `amd64-pc-solaris2.11`.
Currently, clang rejects the following explicit specialization of `f`
due to the constraints not being equivalent:
```
template<typename T>
struct A
{
template<bool B>
void f() requires B;
};
template<>
template<bool B>
void A<int>::f() requires B { }
```
This happens because, in most cases, we do not set the flag indicating
whether a `RedeclarableTemplate` is an explicit specialization of a
member of an implicitly instantiated class template specialization until
_after_ we compare constraints for equivalence. This patch addresses the
issue (and a number of other issues) by:
- storing the flag indicating whether a declaration is a member
specialization on a per declaration basis, and
- significantly refactoring `Sema::getTemplateInstantiationArgs` so we
collect the right set of template argument in all cases.
Many of our declaration matching & constraint evaluation woes can be
traced back to bugs in `Sema::getTemplateInstantiationArgs`. This
change/refactor should fix a lot of them. It also paves the way for
fixing #101330 and #105462 per my suggestion in #102267 (which I have
implemented on top of this patch but will merge in a subsequent PR).
The previous implementation had a bug where, if it was called on a Decl
later in the redecl chain than `LastCheckedDecl`, it could incorrectly
skip and overlook a Decl with a comment.
The patch addresses this by only using `LastCheckedDecl` if the input
Decl `D` is on the path from the first (canonical) Decl to
`LastCheckedDecl`.
An alternative that was considered was to start the iteration from the
(canonical) Decl, however this ran into problems with the modelling of
explicit template specializations in the AST where the canonical Decl
can be unusual. With the current solution, if no Decls were checked yet,
we prefer to check the input Decl over the canonical one.
Fixes https://github.com/llvm/llvm-project/issues/108145
from PEP8
(https://peps.python.org/pep-0008/#programming-recommendations):
> Comparisons to singletons like None should always be done with is or
is not, never the equality operators.
Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>
Resolve#94928
This PR adds `if (TD->getTemplateDecl())` to prevent `InnerD` becoming
`nullptr`, suggested by @firstmoonlight.
I also add `-ast-dump-decl-types` option and declare type `CHECK` to the
testcase `clang/test/AST/ast-dump-concepts.cpp`.
---------
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Add new elementwise popcount builtin to support HLSL function
'countbits'.
elementwise popcount only accepts integer types.
Add hlsl intrinsic 'countbits'
Closes#99094
clang-rename has largely been superseded by clangd and this project
hasn't received much attention in many years. Further, our
documentation on it still claims it's in very early stages of
development despite being ~10 years old. One of the primary people
driving the tool has mentioned that they don't believe there is a
reason to continue to support it unless it's still being actively
used (https://reviews.llvm.org/D148439#4303202) and I've found no
evidence to suggest that is the case.
Original RFC:
https://discourse.llvm.org/t/rfc-time-to-deprecate-remove-clang-rename/70707
When rebuilding immediate invocations inside
`RemoveNestedImmediateInvocation()`, we employed a `TreeTransform` to
exercise the traversal. The transformation has a side effect that, for
template specialization types, their default template arguments are
substituted separately, and if any lambdas are present, they will be
transformed into distinct types than those used to instantiate the
templates right before the `consteval` handling.
This resulted in `B::func()` getting redundantly instantiated for the
case in question. Since we're also in an immediate evaluation context,
the body of `foo()` would also get instantiated, so we end up with a
spurious friend redefinition error.
Like what we have done in `ComplexRemove`, this patch also avoids the
lambda's transformation in TemplateInstantiator if we know we're
rebuilding immediate calls. In addition, this patch also consolidates
the default argument substitution logic in
`CheckTemplateArgumentList()`.
Fixes#107175
Fixed an assertion failure in debug mode, and potential crashes in
release mode, when
diagnosing a failed cast caused indirectly by a failed implicit
conversion to the type of the constructor parameter.
For instance
```
template<typename>
struct StringTrait {};
template< int N >
struct StringTrait< const char[ N ] > {
typedef char CharType;
static const MissingIntT length = N - 1;
};
class String {
public:
template <typename T>
String(T& str, typename StringTrait<T>::CharType = 0);
};
class Exception {
public:
Exception(String const&);
};
void foo() {
throw Exception("some error");
}
```
`Exception(String const&)` is a matching constructor for `Exception`
from a `const char*`, via an implicit conversion to `String`. However,
the instantiation of the `String` constructor will fail because of the
missing type `MissingIntT` inside the specialization of `StringTrait`.
When trying to emit a diagnosis, `tryDiagnoseOverloadedCast` expects not
to have a matching constructor, but there is; it just could not be
instantiated.
https://cplusplus.github.io/CWG/issues/2915.html
Previously, `struct A { void f(this void); };` was accepted with `A::f`
being a member function with no non-object arguments, but it was still a
little wonky because it was still considered an explicit object member
function. Now, this is rejected immediately.
This applies to any language mode with explicit object parameters as
this is a DR (C++23 and C++26)
In the GSL analysis, we don't track the `this` object if the conversion
is not from gsl::owner to gsl pointer, we want to be conservative here
to avoid triggering false positives.
Fixes#108272
This adds new Clang flags to support codegen (CG) data:
- `-fcodegen-data-generate{=path}`: This flag passes
`-codegen-data-generate` as a boolean to the LLVM backend, causing the
raw CG data to be emitted into a custom section. Currently, for LLD
MachO only, it also passes `--codegen-data-generate-path=<path>` so that
the indexed CG data file can be automatically produced at link time. For
linkers that do not yet support this feature, `llvm-cgdata` can be used
manually to merge this CG data in object files.
- `-fcodegen-data-use{=path}`: This flag passes
`-codegen-data-use-path=<path>` to the LLVM backend, enabling the use of
specified CG data to optimistically outline functions.
- The default `<path>` is set to `default.cgdata` when not specified.
This depends on https://github.com/llvm/llvm-project/pull/108733.
This is a patch for
https://discourse.llvm.org/t/rfc-enhanced-machine-outliner-part-2-thinlto-nolto/78753.
Recently, there are multiple false positive issue reports about the
reachability of implementation partition units:
- https://github.com/llvm/llvm-project/issues/105882
- https://github.com/llvm/llvm-project/issues/101348
- https://lists.isocpp.org/core/2024/08/16232.php
And according to our use experience for modules, we find it is a pretty
good practice to not import implementation partition units in the
interface units. It can help developers to have a pretty good mental
model for when to use an implementation partition unit: that any unit in
the module but not in the module interfaces can be in the implementation
partition unit.
So I think it is good to add the diagnostics.
Basically clang already implemented 90% of the feature as an extension.
This commit disables warnings for C23 and aligns types of enumerators
according to the recent wording.
(In reference to 5901d82ea0)
Consider when `Input[I]` is a `VarDecl` with parameter pack. We would
have already expanded the pack before the code change in the loop`for
(unsigned I = 0; I != *NumExpansions; ++I) {`.
Now in `if (RetainExpansion) {`, without this change, we continue to
substitute the pack in the pattern even when we do not have meaningful
`ArgumentPackSubstitutionIndex` set.
This leads to use of an invalid pack substitution index in
`TemplateInstantiator::TransformFunctionParmPackRefExpr` in
`TransformedDecl = (*Pack)[getSema().ArgumentPackSubstitutionIndex];`
This change sets `ArgumentPackSubstitutionIndex` to `-1` while retaining
expansion to instruct `TransformFunctionParmPackRefExpr` to build
`FunctionParmPackExpr` instead of substituting the param pack.
---
There are other instances of `RetainExpansion` and IIUC, they should
also unset the `ArgumentPackSubstitutionIndex`. It would be great if
someone can verify my understanding. If this is correct then we could
instead have a `ArgumentPackSubstitutionIndexRAII` as part of
`ForgetPartiallySubstitutedPackRAII`.
EDIT: I have moved this to `ForgetPartiallySubstitutedPackRAII`.
Fixes https://github.com/llvm/llvm-project/issues/63819
Fixes https://github.com/llvm/llvm-project/issues/107560
Since #93433, we have switched to `QualifiedTemplateName`s in more
situations to preserve sugars in diagnostics. However, there is one
missed case in typo correction that might not meet the expectation in
`CheckDeductionGuideDeclarator()`.
Fixes https://github.com/llvm/llvm-project/issues/107887
The PR reapply https://github.com/llvm/llvm-project/pull/97308.
- Implement [CWG1815](https://wg21.link/CWG1815): Support lifetime
extension of temporary created by aggregate initialization using a
default member initializer.
- Fix crash that introduced in
https://github.com/llvm/llvm-project/pull/97308. In
`InitListChecker::FillInEmptyInitForField`, when we enter
rebuild-default-init context, we copy all the contents of the parent
context to the current context, which will cause the `MaybeODRUseExprs`
to be lost. But we don't need to copy the entire context, only the
`DelayedDefaultInitializationContext` was required, which is used to
build `SourceLocExpr`, etc.
---------
Signed-off-by: yronglin <yronglin777@gmail.com>
This pull request enhances the GSL lifetime analysis to detect
situations where a dangling `Container<GSLPointer>` object is
constructed:
```cpp
std::vector<std::string_view> bad = {std::string()}; // dangling
```
The assignment case is not yet supported, but they will be addressed in
a follow-up.
Fixes#100526 (excluding the `push_back` case).
This reverts commit 45c8766973bb3bb73dd8d996231e114dcf45df9f
and 049512e39d96995cb373a76cf2d009a86eaf3aab.
This change triggers failed asserts on inputs like this:
struct a {
} constexpr b;
class c {
public:
c(a);
};
class B {
public:
using d = int;
struct e {
enum { f } g;
int h;
c i;
d j{};
};
};
B::e k{B::e::f, int(), b};
Compiled like this:
clang -target x86_64-linux-gnu -c repro.cpp
clang: ../../clang/lib/CodeGen/CGExpr.cpp:3105: clang::CodeGen::LValue
clang::CodeGen::CodeGenFunction::EmitDeclRefLValue(const clang::DeclRefExpr*):
Assertion `(ND->isUsed(false) || !isa<VarDecl>(ND) || E->isNonOdrUse() ||
!E->getLocation().isValid()) && "Should not use decl without marking it used!"' failed.
`FunctionParmPackExpr`s are peculiar in that they have to be of
unexpanded dependency while they don't introduce any unexpanded packs.
So this patch rules them out in the non-empty pack assertion in
`DiagnoseUnexpandedParameterPack()`.
There was a fix#69224, but that turned out to be insufficient.
I also moved the separate tests to a pre-existing file.
Fixes https://github.com/llvm/llvm-project/issues/86361
This patch is the frontend implementation of the coroutine elide
improvement project detailed in this discourse post:
https://discourse.llvm.org/t/language-extension-for-better-more-deterministic-halo-for-c-coroutines/80044
This patch proposes a C++ struct/class attribute
`[[clang::coro_await_elidable]]`. This notion of await elidable task
gives developers and library authors a certainty that coroutine heap
elision happens in a predictable way.
Originally, after we lower a coroutine to LLVM IR, CoroElide is
responsible for analysis of whether an elision can happen. Take this as
an example:
```
Task foo();
Task bar() {
co_await foo();
}
```
For CoroElide to happen, the ramp function of `foo` must be inlined into
`bar`. This inlining happens after `foo` has been split but `bar` is
usually still a presplit coroutine. If `foo` is indeed a coroutine, the
inlined `coro.id` intrinsics of `foo` is visible within `bar`. CoroElide
then runs an analysis to figure out whether the SSA value of
`coro.begin()` of `foo` gets destroyed before `bar` terminates.
`Task` types are rarely simple enough for the destroy logic of the task
to reference the SSA value from `coro.begin()` directly. Hence, the pass
is very ineffective for even the most trivial C++ Task types. Improving
CoroElide by implementing more powerful analyses is possible, however it
doesn't give us the predictability when we expect elision to happen.
The approach we want to take with this language extension generally
originates from the philosophy that library implementations of `Task`
types has the control over the structured concurrency guarantees we
demand for elision to happen. That is, the lifetime for the callee's
frame is shorter to that of the caller.
The ``[[clang::coro_await_elidable]]`` is a class attribute which can be
applied to a coroutine return type.
When a coroutine function that returns such a type calls another
coroutine function, the compiler performs heap allocation elision when
the following conditions are all met:
- callee coroutine function returns a type that is annotated with
``[[clang::coro_await_elidable]]``.
- In caller coroutine, the return value of the callee is a prvalue that
is immediately `co_await`ed.
From the C++ perspective, it makes sense because we can ensure the
lifetime of elided callee cannot exceed that of the caller if we can
guarantee that the caller coroutine is never destroyed earlier than the
callee coroutine. This is not generally true for any C++ programs.
However, the library that implements `Task` types and executors may
provide this guarantee to the compiler, providing the user with
certainty that HALO will work on their programs.
After this patch, when compiling coroutines that return a type with such
attribute, the frontend checks that the type of the operand of
`co_await` expressions (not `operator co_await`). If it's also
attributed with `[[clang::coro_await_elidable]]`, the FE emits metadata
on the call or invoke instruction as a hint for a later middle end pass
to elide the elision.
The original patch version is
https://github.com/llvm/llvm-project/pull/94693 and as suggested, the
patch is split into frontend and middle end solutions into stacked PRs.
The middle end CoroSplit patch can be found at
https://github.com/llvm/llvm-project/pull/99283
The middle end transformation that performs the elide can be found at
https://github.com/llvm/llvm-project/pull/99285
This extends default argument deduction to cover class templates as
well, applying only to partial ordering, adding to the provisional
wording introduced in https://github.com/llvm/llvm-project/pull/89807.
This solves some ambuguity introduced in P0522 regarding how template
template parameters are partially ordered, and should reduce the
negative impact of enabling `-frelaxed-template-template-args` by
default.
Given the following example:
```C++
template <class T1, class T2 = float> struct A;
template <class T3> struct B;
template <template <class T4> class TT1, class T5> struct B<TT1<T5>>; // #1
template <class T6, class T7> struct B<A<T6, T7>>; // #2
template struct B<A<int>>;
```
Prior to P0522, `#2` was picked. Afterwards, this became ambiguous. This
patch restores the pre-P0522 behavior, `#2` is picked again.
The primary motivation is to remove `EntryCount` from `FunctionSummary`.
This frees 8 bytes out of `sizeof(FunctionSummary)` (136 bytes as of
64498c5483).
While I'm at it, this PR clean up {SummaryBasedOptimizations,
SyntheticCountsPropagation} since they were not used and there are no
plans to further invest on them.
With this patch, bitcode writer writes a placeholder 0 at the byte
offset of `EntryCount` and bitcode reader can parse the function entry
count at the correct byte offset. Added a TODO to stop writing
`EntryCount` and bump bitcode version
The warning is not emitted for the case `string_view c =
std::vector<std::string>({""}).at(0);` because we bail out during the
visit of the LHS at [this
point](5d2c324fea/clang/lib/Sema/CheckExprLifetime.cpp (L341-L343))
in the code.
This bailout was introduced in [this
commit](bcd0798c47)
to address a false positive with
`vector<vector::iterator>({""}).at(0);`. This PR refines that fix by
ensuring that, for initialization involving a gsl-pointer, we only
consider constructor calls that take the gsl-owner object.
Fixes#100384.
Parsing lambdas require pushing a declaration context for the lambda, so
that parameters can be attached to it, before its trailing type is
parsed. DAt that point, partially-parsed lambda don't have a name that
can be computed for then.
This would cause source_location::current() to crash when use in the
decltype of a lambda().
We work around this by producing a source_location for an enclosing
scope in that scenario.
Fixes#67134
Added a new `-Wpre-c++26-compat` warning for when this feature is used
in C++26 and a `-Wc++26-extensions` warning for when this is used in
C++11 through C++23.
---------
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
[P2641R4](https://wg21.link/P2641R4)
This new builtin function is declared `consteval`. Support for
`-fexperimental-new-constant-interpreter` will be added in a later
patch.
---------
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
https://cplusplus.github.io/CWG/issues/2749.html
This DR's effects are backported to C++98.
Does not affect C where integral constant expressions cannot involve
pointers.
---------
Co-authored-by: Vlad Serebrennikov <serebrennikov.vladislav@gmail.com>
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
