Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3
# a760df31 08-Aug-2024 Mital Ashok <mital@mitalashok.co.uk>

[Clang] Implement CWG2137 (list-initialization from objects of the same type) (#94355)

[CWG2137](https://cplusplus.github.io/CWG/issues/2137.html)

This was previously implemented and then reverte

[Clang] Implement CWG2137 (list-initialization from objects of the same type) (#94355)

[CWG2137](https://cplusplus.github.io/CWG/issues/2137.html)

This was previously implemented and then reverted in Clang 18 as #77768

This also implements a workaround for
[CWG2311](https://cplusplus.github.io/CWG/issues/2311.html), similarly
to the 2024-03-01 comment for
[CWG2742](https://cplusplus.github.io/CWG/issues/2742.html).

The exact wording this tries to implement, relative to the C++26 draft:

[over.match.list]p(1.2)

> Otherwise, or if no viable initializer-list constructor is found
<ins>and the initializer list does not consist of exactly a single
element with the same cv-unqualified class type as `T`</ins>, overload
resolution is performed again, [...]

[dcl.init.list]p(3.7)

> Otherwise, if `T` is a class type, constructors are considered. The
applicable constructors are enumerated and the best one is chosen
through overload resolution. <ins>If no constructor is found and the
initializer list consists of exactly a single element with the same
cv-unqualified class type as `T`, the object is initialized from that
element (by copy-initialization for copy-list-initialization, or by
direct-initialization for direct-list-initialization). Otherwise,</ins>
if a narrowing conversion (see below) is required [...]

show more ...


Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init
# 3b639d7d 02-Jul-2024 Younan Zhang <zyn7109@gmail.com>

[Clang] Clarify diagnostic notes for implicitly generated deduction guides (#96084)

Given the following invalid code,
```cpp
template <class T>
struct S {
T *a;
};
S s = {1};
```
we produc

[Clang] Clarify diagnostic notes for implicitly generated deduction guides (#96084)

Given the following invalid code,
```cpp
template <class T>
struct S {
T *a;
};
S s = {1};
```
we produce such diagnostics currently:
```
<source>:2:8: note: candidate template ignored: could not match 'S<T>' against 'int'
2 | struct S {
| ^
<source>:2:8: note: candidate template ignored: could not match 'T *' against 'int'
```
Which I think is confusing because there's no `S<T>` nor `T *` at the
location it points to. This is because we're deducing the initializer
against implicitly generated deduction guides, and their source
locations just point to the corresponding `RecordDecl`. Hence the
misleading notes.

This patch alleviates the issue by adding extra notes demonstrating
which implicit deduction guide we're deducing against. In other words,
in addition to the note of `could not match 'T *' against 'int'`, we
would also say the implicit deduction guide we're trying to use:
`template <class T> S(T *) -> S<T>`, which looks clearer IMO.

---------

Co-authored-by: Sirraide <aeternalmail@gmail.com>

show more ...


Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5
# df762a16 29-Apr-2024 Mital Ashok <mital@mitalashok.co.uk>

[SemaCXX] Recognise initializer_list injected-class-name types as initializer_lists (#90210)

This allows the implicitly-generated deduction guide for the copy
constructor to be recognised as an ini

[SemaCXX] Recognise initializer_list injected-class-name types as 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

show more ...


Revision tags: llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2
# 7415524b 08-Mar-2024 Haojian Wu <hokein.wu@gmail.com>

[clang] Implement CTAD for type alias template. (#77890)

Fixes #54051

This patch implements the C++20 feature -- CTAD for alias templates (P1814R0, specified in https://eel.is/c++draft/over.match

[clang] Implement CTAD for type alias template. (#77890)

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;

show more ...


Revision tags: llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init
# f725bb96 16-Jan-2024 Haojian Wu <hokein.wu@gmail.com>

[clang] Fix CTAD not work for function-type and array-type arguments. (#78159)

Fixes https://github.com/llvm/llvm-project/issues/51710.

When transforming a constructor into a corresponding deduct

[clang] Fix CTAD not work for function-type and array-type arguments. (#78159)

Fixes https://github.com/llvm/llvm-project/issues/51710.

When transforming a constructor into a corresponding deduction guide,
the decayed types (function/array type) were not handled properly which
made clang fail to compile valid code. The patch teaches clang handle
these decayed type in the transformation.

show more ...


Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1
# f1b0a4fc 01-Apr-2022 Richard Smith <richard@metafoo.co.uk>

An expression should only contain an unexpanded parameter pack if it
lexically contains a mention of the pack.

Systematically distinguish between syntactic and semantic references to
packs, especial

An expression should only contain an unexpanded parameter pack if it
lexically contains a mention of the pack.

Systematically distinguish between syntactic and semantic references to
packs, especially when propagating dependence from a type into an
expression. We should consult the type-as-written when computing
syntactic dependence and should consult the semantic type when computing
semantic dependence.

Fixes #54402.

show more ...


Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1
# c9e46219 12-Nov-2021 Matheus Izvekov <mizvekov@gmail.com>

[clang] retain type sugar in auto / template argument deduction

This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses th

[clang] retain type sugar in auto / template argument deduction

This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses the sugared type all the way
down. It would previously lose the sugar on first recursion.
* Undeduced AutoType will be properly canonicalized, including the constraint
template arguments.
* Remove the decltype node created from the decltype(auto) deduction.

As a result, we start seeing sugared types in a lot more test cases,
including some which showed very unfriendly `type-parameter-*-*` types.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: rsmith, #libc, ldionne

Differential Revision: https://reviews.llvm.org/D110216

show more ...


# 6438a52d 14-Nov-2021 Matheus Izvekov <mizvekov@gmail.com>

Revert "[clang] retain type sugar in auto / template argument deduction"

This reverts commit 4d8fff477e024698facd89741cc6cf996708d598.


# 4d8fff47 12-Nov-2021 Matheus Izvekov <mizvekov@gmail.com>

[clang] retain type sugar in auto / template argument deduction

This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses th

[clang] retain type sugar in auto / template argument deduction

This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses the sugared type all the way
down. It would previously lose the sugar on first recursion.
* Undeduced AutoType will be properly canonicalized, including the constraint
template arguments.
* Remove the decltype node created from the decltype(auto) deduction.

As a result, we start seeing sugared types in a lot more test cases,
including some which showed very unfriendly `type-parameter-*-*` types.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D110216

show more ...


# 1d7fdbbc 12-Nov-2021 Adrian Kuegel <akuegel@google.com>

Revert "[clang] retain type sugar in auto / template argument deduction"

This reverts commit 9b6036deedf28e10d797fc4ca734d57680d18053.
Breaks two libc++ tests.


Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3
# 9b6036de 13-Sep-2021 Matheus Izvekov <mizvekov@gmail.com>

[clang] retain type sugar in auto / template argument deduction

This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses th

[clang] retain type sugar in auto / template argument deduction

This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses the sugared type all the way
down. It would previously lose the sugar on first recursion.
* Undeduced AutoType will be properly canonicalized, including the constraint
template arguments.
* Remove the decltype node created from the decltype(auto) deduction.

As a result, we start seeing sugared types in a lot more test cases,
including some which showed very unfriendly `type-parameter-*-*` types.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D110216

show more ...


# 25b3370f 11-Oct-2021 Richard Smith <richard@metafoo.co.uk>

PR52139: Properly handle more kinds of declaration when checking for
usage of an abstract class type within itself.

We were missing handling for deduction guides (which would assert),
friend declara

PR52139: Properly handle more kinds of declaration when checking for
usage of an abstract class type within itself.

We were missing handling for deduction guides (which would assert),
friend declarations, and variable templates. We were mishandling inline
variables and other variables defined inside the class definition.

These diagnostics should be downgraded to warnings, or perhaps removed
entirely, once we implement P0929R2.

show more ...


Revision tags: llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4
# 8f80c66b 23-Mar-2021 Kadir Cetinkaya <kadircet@google.com>

[clang] Fix a crash when CTAD fails

Differential Revision: https://reviews.llvm.org/D99145


Revision tags: llvmorg-12.0.0-rc3
# 4e1c4870 04-Mar-2021 Adam Czachorowski <adamcz@google.com>

[clang] Fix crash when creating deduction guide.

We used to trigger assertion when transforming c-tor with unparsed
default argument. Now we ignore such constructors for this purpose.

Differential

[clang] Fix crash when creating deduction guide.

We used to trigger assertion when transforming c-tor with unparsed
default argument. Now we ignore such constructors for this purpose.

Differential Revision: https://reviews.llvm.org/D97965

show more ...


Revision tags: llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1
# f7f2e426 13-Oct-2020 Richard Smith <richard@metafoo.co.uk>

PR47805: Use a single object for a function parameter in the caller and
callee in constant evaluation.

We previously made a deep copy of function parameters of class type when
passing them, resultin

PR47805: Use a single object for a function parameter in the caller and
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.

show more ...


# 69f7c006 14-Oct-2020 Richard Smith <richard@metafoo.co.uk>

Revert "PR47805: Use a single object for a function parameter in the caller and"

Breaks a clangd unit test.

This reverts commit 8f8b9f2cca0b73314342c721186ae9c860ca273c.


# 8f8b9f2c 13-Oct-2020 Richard Smith <richard@metafoo.co.uk>

PR47805: Use a single object for a function parameter in the caller and
callee in constant evaluation.

We previously made a deep copy of function parameters of class type when
passing them, resultin

PR47805: Use a single object for a function parameter in the caller and
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.

show more ...


# ab870f30 13-Oct-2020 Richard Smith <richard@metafoo.co.uk>

Revert "PR47805: Use a single object for a function parameter in the caller and"

The buildbots are displeased.

This reverts commit 8d03a972ce8e92815ffe3d5d86aa027605ed92e2.


# 8d03a972 13-Oct-2020 Richard Smith <richard@metafoo.co.uk>

PR47805: Use a single object for a function parameter in the caller and
callee in constant evaluation.

We previously made a deep copy of function parameters of class type when
passing them, resultin

PR47805: Use a single object for a function parameter in the caller and
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.

show more ...


# d1751d14 09-Oct-2020 Richard Smith <richard@metafoo.co.uk>

PR47175: Ensure type-dependent function-style casts have dependent
types.

Previously, a type-dependent cast to a deduced class template
specialization type would end up with a non-dependent class te

PR47175: Ensure type-dependent function-style casts have dependent
types.

Previously, a type-dependent cast to a deduced class template
specialization type would end up with a non-dependent class template
specialization type, leading to confusion downstream.

show more ...


Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2
# 98b4b457 05-Aug-2020 Bruno Ricci <riccibrun@gmail.com>

[clang][NFC] Add a test showcasing an unnamed template parameter in a diagnostic


Revision tags: llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4
# 6d894afd 06-Mar-2020 Richard Smith <richard@metafoo.co.uk>

PR45124: Don't leave behind pending cleanups when declaring implicit
deduction guides.

Previously if an implicit deduction guide had a default argument with a
cleanup, we'd leave the 'pending cleanu

PR45124: Don't leave behind pending cleanups when declaring implicit
deduction guides.

Previously if an implicit deduction guide had a default argument with a
cleanup, we'd leave the 'pending cleanup' flag set after declaring the
implicit guide. But it turns out that there's no reason to even
substitute into the default argument when declaring an implicit
deduction guide: we only need to record that the default argument
exists, not what it is, since we never actually form a call to a
deduction guide.

show more ...


Revision tags: llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3
# cb167c85 24-Aug-2019 Richard Smith <richard-llvm@metafoo.co.uk>

PR42513: Enter the proper DeclContext before substituting into an
default template argument expression.

We already did this for type template parameters and template template
parameters, but apparen

PR42513: Enter the proper DeclContext before substituting into an
default template argument expression.

We already did this for type template parameters and template template
parameters, but apparently forgot to do so for non-type template
parameters. This causes the substituted default argument expression to
be substituted in the proper context, and in particular to properly mark
its subexpressions as odr-used.

llvm-svn: 369834

show more ...


Revision tags: llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3
# b63e5774 14-Jun-2019 Gauthier Harnisch <tyker1@outlook.com>

[clang] Fixing incorrect implicit deduction guides (PR41549)

Summary:
[[ https://bugs.llvm.org/show_bug.cgi?id=41549 | bug report ]]

Before this patch, implicit deduction guides were generated from

[clang] Fixing incorrect implicit deduction guides (PR41549)

Summary:
[[ https://bugs.llvm.org/show_bug.cgi?id=41549 | bug report ]]

Before this patch, implicit deduction guides were generated from the first declaration found by lookup.
With this patch implicit deduction guides are generated from the definition of the class template.
Also added test that was previously failing.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits, Quuxplusone

Tags: #clang

Differential Revision: https://reviews.llvm.org/D63072

llvm-svn: 363361

show more ...


Revision tags: llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1
# 73b51ae1 17-Jan-2019 Eric Fiselier <eric@efcs.ca>

Add -Wctad-maybe-unsupported to diagnose CTAD on types with no user defined deduction guides.

Summary:
Some style guides want to allow using CTAD only on types that "opt-in"; i.e. on types that are

Add -Wctad-maybe-unsupported to diagnose CTAD on types with no user defined deduction guides.

Summary:
Some style guides want to allow using CTAD only on types that "opt-in"; i.e. on types that are designed to support it and not just types that *happen* to work with it.

This patch implements the `-Wctad-maybe-unsupported` warning, which is off by default, which warns when CTAD is used on a type that does not define any deduction guides.

The following pattern can be used to suppress the warning in cases where the type intentionally doesn't define any deduction guides:

```
struct allow_ctad_t;

template <class T>
struct TestSuppression {
TestSuppression(T) {}
};
TestSuppression(allow_ctad_t)->TestSuppression<void>; // guides with incomplete parameter types are never considered.
```

Reviewers: rsmith, james.dennett, gromer

Reviewed By: rsmith

Subscribers: jdennett, Quuxplusone, lebedev.ri, cfe-commits

Differential Revision: https://reviews.llvm.org/D56731

llvm-svn: 351484

show more ...


12