| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fixes two issues in two ways:
1) The `braced-init-list` consisted of `initializer-list` and
`designated-initializer-list`, and thus the designated initializer is
subject to [over.match.class.deduct]p1.8, which means the brace elision
is also applicable on it for CTAD deduction guides.
2) When forming a deduction guide where the brace elision is applicable,
we should also consider the presence of braces within the initializer.
For example, given
template <class T, class U> struct X {
T t[2];
U u[3];
};
X x = {{1, 2}, 3, 4, 5};
we should establish such deduction guide AFAIU: `X(T (&&)[2], U, U, U) -> X<T, U>`.
Fixes https://github.com/llvm/llvm-project/issues/64625
Fixes https://github.com/llvm/llvm-project/issues/83368
|
|
and Obj-C++ by-proxy)" (#95299)
Reverts llvm/llvm-project#68620
Introduce or expose a memory leak and UB, see llvm/llvm-project#68620
|
|
Obj-C++ by-proxy) (#68620)
This commit implements the entirety of the now-accepted [N3017 -
Preprocessor
Embed](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm) and
its sister C++ paper [p1967](https://wg21.link/p1967). It implements
everything in the specification, and includes an implementation that
drastically improves the time it takes to embed data in specific
scenarios (the initialization of character type arrays). The mechanisms
used to do this are used under the "as-if" rule, and in general when the
system cannot detect it is initializing an array object in a variable
declaration, will generate EmbedExpr AST node which will be expanded
by AST consumers (CodeGen or constant expression evaluators) or
expand embed directive as a comma expression.
---------
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
Co-authored-by: H. Vetinari <h.vetinari@gmx.com>
Co-authored-by: Podchishchaeva, Mariya <mariya.podchishchaeva@intel.com>
|
|
This addresses a clang-tidy suggestion.
|
|
created by aggregate initialization using a default member initializer" (#92527)" (#94600)
Reverting due to
https://github.com/llvm/llvm-project/pull/92527#issuecomment-2149120420.
This reverts commit f049d72ac2bcc40fd91d4e95148658021fb24bf1.
Co-authored-by: Bogdan Graur <bgraur@google.com>
|
|
(#91692)
Make sure we count the anonymous union as an initialized field, so we
properly construct the AST.
Included bonus testcase Test3, which shows a remaining gap: an anonymous
union can contain a partially initialized anonymous struct, and we
handle that inconsistently.
Fixes #91257
|
|
aggregate initialization using a default member initializer" (#92527)
This PR reapply https://github.com/llvm/llvm-project/pull/87933
Signed-off-by: yronglin <yronglin777@gmail.com>
|
|
Based on @OfekShochat's https://reviews.llvm.org/D133648
init.c is the primary test for array initialization, but it uses a
32-bit triple, which would lead to an "array is too large" error. Add
the new test to array-init.c instead.
Fix #57353
Pull Request: https://github.com/llvm/llvm-project/pull/92473
|
|
aggregate initialization using a default member initializer (#87933)"
This reverts commit 17daa204feadf9c28fc13b7daa69c3cbe865b238.
Multiple examples on the PR
https://github.com/llvm/llvm-project/pull/87933
show regressions, so reverting until they can be fixed in the followup.
|
|
This is continuation of efforts to split `Sema` up, following the
example of OpenMP, OpenACC, etc. Context can be found in
https://github.com/llvm/llvm-project/pull/82217 and
https://github.com/llvm/llvm-project/pull/84184.
I split formatting changes into a separate commit to help reviewing the
actual changes.
|
|
aggregate initialization using a default member initializer (#87933)
This PR complete [DR1815](https://wg21.link/CWG1815) under the guidance
of `FIXME` comments. And reuse `CXXDefaultInitExpr` rewrite machinery to
clone the initializer expression on each use that would lifetime extend
its temporaries.
---------
Signed-off-by: yronglin <yronglin777@gmail.com>
|
|
exception specification of a function (#90760)
[temp.deduct.general] p6 states:
> At certain points in the template argument deduction process it is
necessary to take a function type that makes use of template parameters
and replace those template parameters with the corresponding template
arguments.
This is done at the beginning of template argument deduction when any
explicitly specified template arguments are substituted into the
function type, and again at the end of template argument deduction when
any template arguments that were deduced or obtained from default
arguments are substituted.
[temp.deduct.general] p7 goes on to say:
> The _deduction substitution loci_ are
> - the function type outside of the _noexcept-specifier_,
> - the explicit-specifier,
> - the template parameter declarations, and
> - the template argument list of a partial specialization
>
> The substitution occurs in all types and expressions that are used in
the deduction substitution loci. [...]
Consider the following:
```cpp
struct A
{
static constexpr bool x = true;
};
template<typename T, typename U>
void f(T, U) noexcept(T::x); // #1
template<typename T, typename U>
void f(T, U*) noexcept(T::y); // #2
template<>
void f<A>(A, int*) noexcept; // clang currently accepts, GCC and EDG reject
```
Currently, `Sema::SubstituteExplicitTemplateArguments` will substitute
into the _noexcept-specifier_ when deducing template arguments from a
function declaration or when deducing template arguments for taking the
address of a function template (and the substitution is treated as a
SFINAE context). In the above example, `#1` is selected as the primary
template because substitution of the explicit template arguments into
the _noexcept-specifier_ of `#2` failed, which resulted in the candidate
being ignored.
This behavior is incorrect ([temp.deduct.general] note 4 says as much), and
this patch corrects it by deferring all substitution into the
_noexcept-specifier_ until it is instantiated.
As part of the necessary changes to make this patch work, the
instantiation of the exception specification of a function template
specialization when taking the address of a function template is changed
to only occur for the function selected by overload resolution per
[except.spec] p13.1 (as opposed to being instantiated for every candidate).
|
|
Temporary" (#89942)
Implement P2748R5 "Disallow Binding a Returned Glvalue to a Temporary"
https://wg21.link/P2748R5
---------
Signed-off-by: yronglin <yronglin777@gmail.com>
|
|
initializer_lists (#90210)
This allows the implicitly-generated deduction guide for the copy
constructor to be recognised as an initializer-list constructor,
allowing CTAD for std::initializer_list
|
|
OpenACC is going to need an array sections implementation that is a
simpler version/more restrictive version of the OpenMP version.
This patch moves `OMPArraySectionExpr` to `Expr.h` and renames it `ArraySectionExpr`,
then adds an enum to choose between the two.
This also fixes a couple of 'drive-by' issues that I discovered on the way,
but leaves the OpenACC Sema parts reasonably unimplemented (no semantic
analysis implementation), as that will be a followup patch.
|
|
We always capitalize bitfield as "BitField".
|
|
Convert it to scoped enum, and move it to namespace scope to enable forward declarations.
|
|
Reverts llvm/llvm-project#88546
Leak and performance regression.
Details in #88546
|
|
We were crashing due to stack exhaustion on rather reasonable C++
template code. After some investigation, I found that we have a
stack-allocated object that was huge: `InitializationSequence` was 7016
bytes. This caused an overflow with deep call stacks in initialization
code.
With these change, `InitializationSequence` is now 248 bytes.
With the original code, testing RelWithDebInfo on Windows 10, all the
tests in SemaCXX took about 6s 800ms. The max template depth I could
reach on my machine using the code in the issue was 708. After that, I
would get `-Wstack-exhausted` warnings until crashing at 976
instantiations.
With these changes on the same machine, all the tests in SemaCXX took
about 6s 500ms. The max template depth I could reach was 1492. After
that, I would get `-Wstack-exhausted` warnings until crashing at 2898
instantiations.
This improves the behavior of #88330 but there's still an outstanding
question of why we run out of stack space and crash in some
circumstances before we're able to issue a diagnostic about stack space
exhaustion.
|
|
This implements support for the `= delete("message")` syntax that was
only just added to C++26
([P2573R2](https://isocpp.org/files/papers/P2573R2.html#proposal-scope)).
|
|
In preparation for `SemaCUDA`, which requires this enum to be forward-declarable.
|
|
Fixes https://github.com/llvm/llvm-project/issues/85767.
The aggregate deduction guides are handled in a separate code path. We
don't generate dedicated aggregate deduction guides for alias templates
(we just reuse the ones from the underlying template decl by accident).
The patch fixes this incorrect issue.
Note: there is a small refactoring change in this PR, where we move the
cache logic from `Sema::DeduceTemplateSpecializationFromInitializer` to
`Sema::DeclareImplicitDeductionGuideFromInitList`
|
|
(#82705)" (#87325)
This reverts commit 28760b63bbf9e267713957105a8d17091fb0d20e.
The last commit was missing the new testcase, now fixed.
|
|
HLSL constant sized array function parameters do not decay to pointers.
Instead constant sized array types are preserved as unique types for
overload resolution, template instantiation and name mangling.
This implements the change by adding a new `ArrayParameterType` which
represents a non-decaying `ConstantArrayType`. The new type behaves the
same as `ConstantArrayType` except that it does not decay to a pointer.
Values of `ConstantArrayType` in HLSL decay during overload resolution
via a new `HLSLArrayRValue` cast to `ArrayParameterType`.
`ArrayParamterType` values are passed indirectly by-value to functions
in IR generation resulting in callee generated memcpy instructions.
The behavior of HLSL function calls is documented in the [draft language
specification](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf)
under the Expr.Post.Call heading.
Additionally the design of this implementation approach is documented in
[Clang's
documentation](https://clang.llvm.org/docs/HLSL/FunctionCalls.html)
Resolves #70123
|
|
types (#82705)"" (#87041)
This reverts commit bbbcc1d99d08855069f4501c896c43a6d4d7b598.
This change is causing the following build bots to fail due to a missing
header file:
- https://lab.llvm.org/buildbot/#/builders/188/builds/43765
- https://lab.llvm.org/buildbot/#/builders/176/builds/9428
- https://lab.llvm.org/buildbot/#/builders/187/builds/14696
- https://lab.llvm.org/buildbot/#/builders/186/builds/15551
- https://lab.llvm.org/buildbot/#/builders/182/builds/9413
- https://lab.llvm.org/buildbot/#/builders/245/builds/22507
- https://lab.llvm.org/buildbot/#/builders/258/builds/16026
- https://lab.llvm.org/buildbot/#/builders/249/builds/17221
- https://lab.llvm.org/buildbot/#/builders/38/builds/18566
- https://lab.llvm.org/buildbot/#/builders/214/builds/11735
- https://lab.llvm.org/buildbot/#/builders/231/builds/21947
- https://lab.llvm.org/buildbot/#/builders/230/builds/26675
- https://lab.llvm.org/buildbot/#/builders/57/builds/33922
- https://lab.llvm.org/buildbot/#/builders/124/builds/10311
- https://lab.llvm.org/buildbot/#/builders/109/builds/86173
- https://lab.llvm.org/buildbot/#/builders/280/builds/1043
- https://lab.llvm.org/buildbot/#/builders/283/builds/440
- https://lab.llvm.org/buildbot/#/builders/247/builds/16034
- https://lab.llvm.org/buildbot/#/builders/139/builds/62423
- https://lab.llvm.org/buildbot/#/builders/216/builds/36718
- https://lab.llvm.org/buildbot/#/builders/259/builds/2039
- https://lab.llvm.org/buildbot/#/builders/36/builds/44091
- https://lab.llvm.org/buildbot/#/builders/272/builds/12629
- https://lab.llvm.org/buildbot/#/builders/271/builds/6020
- https://lab.llvm.org/buildbot/#/builders/236/builds/10319
|
|
(#82705)"
This reverts commit ca4c4a6758d184f209cb5d88ef42ecc011b11642.
This was intended not to introduce new consistency diagnostics for
smart pointer types, but failed to ignore sugar around types when
detecting this.
Fixed and test added.
|
|
GNU and MSVC have extensions where flexible array members (or their
equivalent) can be in unions or alone in structs. This is already fully
supported in Clang through the 0-sized array ("fake flexible array")
extension or when C99 flexible array members have been syntactically
obfuscated.
Clang needs to explicitly allow these extensions directly for C99
flexible arrays, since they are common code patterns in active use by
the
Linux kernel (and other projects). Such projects have been using either
0-sized arrays (which is considered deprecated in favor of C99 flexible
array members) or via obfuscated syntax, both of which complicate their
code bases.
For example, these do not error by default:
```
union one {
int a;
int b[0];
};
union two {
int a;
struct {
struct { } __empty;
int b[];
};
};
```
But this does:
```
union three {
int a;
int b[];
};
```
Remove the default error diagnostics for this but continue to provide
warnings under Microsoft or GNU extensions checks. This will allow for
a seamless transition for code bases away from 0-sized arrays without
losing existing code patterns. Add explicit checking for the warnings
under various constructions.
Additionally fixes a CodeGen bug with flexible array members in unions
in C++, which was found when adding a testcase for:
```
union { char x[]; } z = {0};
```
which only had Sema tests originally.
Fixes #84565
|
|
In PR #79382, I need to add a new type that derives from
ConstantArrayType. This means that ConstantArrayType can no longer use
`llvm::TrailingObjects` to store the trailing optional Expr*.
This change refactors ConstantArrayType to store a 60-bit integer and
4-bits for the integer size in bytes. This replaces the APInt field
previously in the type but preserves enough information to recreate it
where needed.
To reduce the number of places where the APInt is re-constructed I've
also added some helper methods to the ConstantArrayType to allow some
common use cases that operate on either the stored small integer or the
APInt as appropriate.
Resolves #85124.
|
|
(#82705)"
This reverts commit 92a09c0165b87032e1bd05020a78ed845cf35661.
This is triggering a bunch of new -Wnullability-completeness warnings
in code with existing raw pointer nullability annotations.
The intent was the new nullability locations wouldn't affect those
warnings, so this is a bug at least for now.
|
|
This enables clang and external nullability checkers to make use of
these annotations on nullable C++ class types like unique_ptr.
These types are recognized by the presence of the _Nullable attribute.
Nullable standard library types implicitly receive this attribute.
Existing static warnings for raw pointers are extended to smart
pointers:
- nullptr used as return value or argument for non-null functions
(`-Wnonnull`)
- assigning or initializing nonnull variables with nullable values
(`-Wnullable-to-nonnull-conversion`)
It doesn't implicitly add these attributes based on the assume_nonnull
pragma, nor warn on missing attributes where the pragma would apply
them.
I'm not confident that the pragma's current behavior will work well for
C++ (where type-based metaprogramming is much more common than C/ObjC).
We'd like to revisit this once we have more implementation experience.
Support can be detected as `__has_feature(nullability_on_classes)`.
This is needed for back-compatibility, as previously clang would issue a
hard error when _Nullable appears on a smart pointer.
UBSan's `-fsanitize=nullability` will not check smart-pointer types.
It can be made to do so by synthesizing calls to `operator bool`, but
that's left for future work.
Discussion:
https://discourse.llvm.org/t/rfc-allowing-nonnull-etc-on-smart-pointers/77201/26
|
|
Fixes #54051
This patch implements the C++20 feature -- CTAD for alias templates (P1814R0, specified in https://eel.is/c++draft/over.match.class.deduct#3). It is an initial patch:
- it cover major pieces, thus it works for most cases;
- the big missing piece is to implement the associated constraints (over.match.class.deduct#3.3) for the synthesized deduction guides, see the FIXME in code and tests;
- Some enhancements on the TreeTransform&TemplateInstantiator to allow performing instantiation on `BuildingDeductionGuides` mode;
|
|
The implementation mostly reuses C++ code paths where possible,
including narrowing check in order to provide diagnostic messages in
case initializer for constexpr variable is not exactly representable in
target type.
The following won't work due to lack of support for other features:
- Diagnosing of underspecified declarations involving constexpr
- Constexpr attached to compound literals
Also due to lack of support for char8_t some of examples with utf-8
strings don't work properly.
Fixes https://github.com/llvm/llvm-project/issues/64742
|
|
#56628 changed the behavior of `-Wmissing-field-initializers`, which
introduces many new warnings in C++ code that uses partial designated
initializers. If such code is being built with `-Wextra -Werror`, this
change will break the build.
This PR adds a new flag that allows to disable these new warnings and
keep the old ones, as was suggested by @AaronBallman in the original
issue:
https://github.com/llvm/llvm-project/issues/56628#issuecomment-1761510850
Fixes #68933
|
|
Emit a warning if pointer/reference to compound literal is returned from
a function.
In C, compound literals in block scope are lvalues that have automatic
storage duration. In C++, compound literals in block scope are
temporaries.
In either case, returning a pointer/reference to a compound literal can
cause a use-after-free bug.
Fixes #8678
|
|
HLSL supports vector truncation and element conversions as part of
standard conversion sequences. The vector truncation conversion is a C++
second conversion in the conversion sequence. If a vector truncation is
in a conversion sequence an element conversion may occur after it before
the standard C++ third conversion.
Vector element conversions can be boolean conversions, floating point or
integral conversions or promotions.
[HLSL Draft
Specification](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf)
---------
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
|
|
Implement P2718R0 "Lifetime extension in range-based for loops"
(https://wg21.link/P2718R0)
Differential Revision: https://reviews.llvm.org/D153701
---------
Signed-off-by: yronglin <yronglin777@gmail.com>
|
|
same type) (#77768)"
This reverts commit 924701311aa79180e86ad8ce43d253f27d25ec7d. Causes compilation
errors on valid code, see
https://github.com/llvm/llvm-project/pull/77768#issuecomment-1908062472.
|
|
Reland of #78387
Use the template pattern in determining whether to synthesize the
aggregate deduction guide, and update
DeclareImplicitDeductionGuideFromInitList to substitute outer template
arguments.
The tests in the original patch made an assumption about the size of a
pointer type, and this led to them failing on targets with 32-bit
pointers. The tests have been updated to not depend on the size of any
type. This only requires updates to the test file, no functionality has
otherwise changed between this and the original patch.
|
|
type) (#77768)
Closes #77638, #24186
Rebased from <https://reviews.llvm.org/D156032>, see there for more
information.
Implements wording change in [CWG2137](https://wg21.link/CWG2137) in the
first commit.
This also implements an approach to [CWG2311](https://wg21.link/CWG2311)
in the second commit, because too much code that relies on `T{ T_prvalue}`
being an elision would break. Because that issue is still open and
the CWG issue doesn't provide wording to fix the issue, there may be
different behaviours on other compilers.
|
|
`new` (#76976)
This bug is caused by parenthesized list initialization not being
implemented in `CodeGenFunction::EmitNewArrayInitializer(...)`.
Parenthesized list initialization of `struct`s with `operator new`
already works in Clang and is not affected by this bug.
Additionally, fix the test new-delete.cpp as it incorrectly assumes that
using parentheses with operator new to initialize arrays is illegal for
C++ versions >= C++17.
Fixes #68198
|
|
(#77066)
### Problem
```cpp
co_task<int> coro() {
int a = 1;
auto lamb = [a]() -> co_task<int> {
co_return a; // 'a' in the lambda object dies after the iniital_suspend in the lambda coroutine.
}();
co_return co_await lamb;
}
```
[use-after-free](https://godbolt.org/z/GWPEovWWc)
Lambda captures (even by value) are prone to use-after-free once the
lambda object dies. In the above example, the lambda object appears only
as a temporary in the call expression. It dies after the first
suspension (`initial_suspend`) in the lambda.
On resumption in `co_await lamb`, the lambda accesses `a` which is part
of the already-dead lambda object.
---
### Solution
This problem can be formulated by saying that the `this` parameter of
the lambda call operator is a lifetimebound parameter. The lambda object
argument should therefore live atleast as long as the return object.
That said, this requirement does not hold if the lambda does not have a
capture list. In principle, the coroutine frame still has a reference to
a dead lambda object, but it is easy to see that the object would not be
used in the lambda-coroutine body due to no capture list.
It is safe to use this pattern inside a`co_await` expression due to the
lifetime extension of temporaries. Example:
```cpp
co_task<int> coro() {
int a = 1;
int res = co_await [a]() -> co_task<int> { co_return a; }();
co_return res;
}
```
---
### Background
This came up in the discussion with seastar folks on
[RFC](https://discourse.llvm.org/t/rfc-lifetime-bound-check-for-parameters-of-coroutines/74253/19?u=usx95).
This is a fairly common pattern in continuation-style-passing (CSP)
async programming involving futures and continuations. Document ["Lambda
coroutine
fiasco"](https://github.com/scylladb/seastar/blob/master/doc/lambda-coroutine-fiasco.md)
by Seastar captures the problem.
This pattern makes the migration from CSP-style async programming to
coroutines very bugprone.
Fixes https://github.com/llvm/llvm-project/issues/76995
---------
Co-authored-by: Chuanqi Xu <yedeng.yd@linux.alibaba.com>
|
|
Reverts llvm/llvm-project#78387
The added tests are failing on several build bots.
|
|
Use the template pattern in determining whether to synthesize the
aggregate deduction guide, and update
DeclareImplicitDeductionGuideFromInitList to substitute outer template
arguments.
Fixes #77599
|
|
(#77278)
|
|
(#76833)
…te initialization" (#76272)""
With updates the libc++ tests.
This reverts commit 2205d23 and relands
86dc6e1 and
7ab16fb.
Original commit was reverted because of failing libc++ tests, see #76232
for the discussion.
The errors in the tests are spurious in the first place (coming from
initialization of invalid classes), so update the tests to match new
behavior that does not show those errors.
The original patch was written by @ilya-biryukov
To fix the CI two libc++ tests are temporary disabled for clang-18.
|
|
Lifetime-bound analysis of reference parameters of coroutines and
coroutine wrappers is helpful in surfacing memory bugs associated with
using temporaries and stack variables in call expressions in plain
return statements.
This is the default semantics of `[[clang::coro_lifetimebound]]`. But it
should be okay to relax the requirements for a function when the
reference arguments are not lifetime bound. For example:
A coroutine wrapper accepts a reference parameter but does not pass it
to the underlying coroutine call.
```cpp
[[clang::coro_wrapper]] Task<int> wrapper(const Request& req) {
return req.shouldCallA() ? coroA() : coroB();
}
```
Or passes it the coroutine by value
```cpp
Task<int> coro(std::string s) { co_return s.size(); }
[[clang::coro_wrapper]] wrapper(const std::string& s) { return coro(s); }
```
This patch allows functions to be annotated with
`[[clang::coro_disable_lifetime_bound]]` to disable lifetime bound
analysis for all calls to this function.
---
One missing piece here is a note suggesting using this annotation in
cases of lifetime warnings. This would require some more tweaks in the
lifetimebound analysis to recognize violations involving coroutines only
and produce this note only in those cases.
|
|
aggregate initialization" (#76272)"
This reverts commit 02347fc7191ff4d073f439dde6523add3f5496de.
These changes break the libc++ CI again.
I'll look at a better solution later.
|
|
initialization" (#76272)
With updates the libc++ tests.
This reverts commit 2205d2334f3c859ad9f6c65ed950bfb3bb6f7cbe and relands
86dc6e15f22610bbb53eb4efda0a178ecefc933a and
7ab16fb5207fe187ab999f882069bd632d2e68e5.
Original commit was reverted because of failing libc++ tests, see #76232 for
the discussion.
The errors in the tests are spurious in the first place (coming from initialization
of invalid classes), so update the tests to match new behavior that does
not show those errors.
|
|
initialization" (#76272)
Reverts llvm/llvm-project#76232 and
7ab16fb5207fe187ab999f882069bd632d2e68e5 to recover build bots.
Breaks libc++ tests, details in #76232
#76228
|
|
https://github.com/llvm/llvm-project/pull/75332 diagnosed narrowing
involving const reference. Our depot has hundreds if not thousands of
breakages
(https://github.com/llvm/llvm-project/pull/75332#issuecomment-1864757240).
Add a subgroup of -Wc++11-narrowing to help users gradually fix their
issues without regressing the existing -Wc++11-narrowing diagnostics.
|
