|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, 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, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, 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, 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, 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 |
|
| #
8a4d388c |
| 06-Apr-2022 |
Jun Zhang <[email protected]> |
[Clang][Sema] Prohibit statement expression in the default argument
As statement expression makes no sense in the default argument,
this patch tries to disable it in the all cases.
Please note that
[Clang][Sema] Prohibit statement expression in the default argument
As statement expression makes no sense in the default argument,
this patch tries to disable it in the all cases.
Please note that the statement expression is a GNU extension, which
means that Clang should be consistent with GCC. However, there's no
response from GCC devs since we have raised the issue for several weeks.
In this case, I think we can disallow statement expressions as a default
parameter in general for now, and relax the restriction if GCC folks
decide to retain the feature for functions but not lambdas in the
future.
Related discussion: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104765
Fixes https://github.com/llvm/llvm-project/issues/53488
Differential Revision: https://reviews.llvm.org/D119609
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, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, 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, llvmorg-12.0.0-rc3, 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 |
|
| #
da986511 |
| 19-Jan-2021 |
Richard Smith <[email protected]> |
Revert "DR2064: decltype(E) is only a dependent type if E is type-dependent, not
if E is merely instantiation-dependent."
This change leaves us unable to distinguish between different function
templ
Revert "DR2064: decltype(E) is only a dependent type if E is type-dependent, not
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 e3065ce238475ec202c707f4c58d90df171626ca.
show more ...
|
|
Revision tags: llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2 |
|
| #
e3065ce2 |
| 17-Dec-2020 |
Richard Smith <[email protected]> |
DR2064: decltype(E) is only a dependent type if E is type-dependent, not
if E is merely instantiation-dependent.
Previously reverted in 34e72a146111dd986889a0f0ec8767b2ca6b2913;
re-committed with a
DR2064: decltype(E) is only a dependent type if E is type-dependent, not
if E is merely instantiation-dependent.
Previously reverted in 34e72a146111dd986889a0f0ec8767b2ca6b2913;
re-committed with a fix to an issue that caused name mangling to assert.
show more ...
|
| #
34e72a14 |
| 22-Dec-2020 |
Arthur Eubanks <[email protected]> |
Revert "DR2064: decltype(E) is only a dependent type if E is type-dependent, not"
This reverts commit 638867afd4bce4a2c56dea041299428af3727d61.
This is part of 5 commits being reverted due to https
Revert "DR2064: decltype(E) is only a dependent type if E is type-dependent, not"
This reverts commit 638867afd4bce4a2c56dea041299428af3727d61.
This is part of 5 commits being reverted due to https://crbug.com/1161059. See bug for repro.
show more ...
|
| #
638867af |
| 17-Dec-2020 |
Richard Smith <[email protected]> |
DR2064: decltype(E) is only a dependent type if E is type-dependent, not
if E is merely instantiation-dependent.
|
|
Revision tags: llvmorg-11.0.1-rc1, 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, llvmorg-11.0.0-rc1, llvmorg-12-init |
|
| #
f721e058 |
| 09-Jul-2020 |
Richard Smith <[email protected]> |
PR46648: Do not eagerly instantiate default arguments for a generic
lambda when instantiating a call operator specialization.
We previously incorrectly thought that such substitution was happening
i
PR46648: Do not eagerly instantiate default arguments for a generic
lambda when instantiating a call operator specialization.
We previously incorrectly thought that such substitution was happening
in the context of substitution into a local scope, which is a context
where we should perform eager default argument instantiation.
show more ...
|
|
Revision tags: 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 |
|
| #
5c845c1c |
| 10-Mar-2020 |
Richard Smith <[email protected]> |
PR45083: Mark statement expressions as being dependent if they appear in
a dependent context.
This matches the GCC behavior.
We track the enclosing template depth when determining whether a
stateme
PR45083: Mark statement expressions as being dependent if they appear in
a dependent context.
This matches the GCC behavior.
We track the enclosing template depth when determining whether a
statement expression is within a dependent context; there doesn't appear
to be any other reliable way to determine this.
We previously assumed they were neither value- nor
instantiation-dependent under any circumstances, which would lead to
crashes and other misbehavior.
show more ...
|
| #
6333cc2a |
| 10-Mar-2020 |
Richard Smith <[email protected]> |
Revert "PR45083: Mark statement expressions as being dependent if they contain"
This reverts commit 2669e41b7b9c1561a01048d5ed0aba3c62432dfc, which was
pushed by mistake.
|
| #
2669e41b |
| 05-Mar-2020 |
Richard Smith <[email protected]> |
PR45083: Mark statement expressions as being dependent if they contain
dependent constructs.
We previously assumed they were neither value- nor
instantiation-dependent under any circumstances, which
PR45083: Mark statement expressions as being dependent if they contain
dependent constructs.
We previously assumed they were neither value- nor
instantiation-dependent under any circumstances, which would lead to
crashes and other misbehavior.
This doesn't match GCC's behavior (where statement expressions appear to
be treated as value-dependent if they appear in a dependent context),
but seems to be the best thing we can do in the short term: it turns out
to be remarkably difficult for us to correctly determine whether we are
in a dependent context (and it's not even possible in some cases, such
as in a generic lambda where we might not have seen the 'auto' yet).
This was previously reverted in 8e4a867 for rejecting some code, but that
code was invalid and Clang was previously incorrectly accepting it.
show more ...
|
| #
8e4a8677 |
| 06-Mar-2020 |
Stephan Herhut <[email protected]> |
Revert "PR45083: Mark statement expressions as being dependent if they contain"
This reverts commit a95cc77be154433c37a3110ac9af394b7447fcba.
Causes an internal build failure. I followed up with th
Revert "PR45083: Mark statement expressions as being dependent if they contain"
This reverts commit a95cc77be154433c37a3110ac9af394b7447fcba.
Causes an internal build failure. I followed up with the author by mail.
show more ...
|
| #
a95cc77b |
| 05-Mar-2020 |
Richard Smith <[email protected]> |
PR45083: Mark statement expressions as being dependent if they contain
dependent constructs.
We previously assumed they were neither value- nor
instantiation-dependent under any circumstances, which
PR45083: Mark statement expressions as being dependent if they contain
dependent constructs.
We previously assumed they were neither value- nor
instantiation-dependent under any circumstances, which would lead to
crashes and other misbehavior.
This doesn't match GCC's behavior (where statement expressions appear to
be treated as value-dependent if they appear in a dependent context),
but seems to be the best thing we can do in the short term: it turns out
to be remarkably difficult for us to correctly determine whether we are
in a dependent context (and it's not even possible in some cases, such
as in a generic lambda where we might not have seen the 'auto' yet).
show more ...
|
| #
66addf8e |
| 05-Mar-2020 |
Benjamin Kramer <[email protected]> |
Revert "Fix regression in bdad0a1: force rebuilding of StmtExpr nodes in", "PR45083: Mark statement expressions as being dependent if they appear in"
This reverts commit f545ede91c9d9f271e7504282cab
Revert "Fix regression in bdad0a1: force rebuilding of StmtExpr nodes in", "PR45083: Mark statement expressions as being dependent if they appear in"
This reverts commit f545ede91c9d9f271e7504282cab7bf509607ead.
This reverts commit bdad0a1b79273733df9acc1be4e992fa5d70ec56.
This crashes clang. I'll follow up with reproduction instructions.
show more ...
|
| #
f545ede9 |
| 04-Mar-2020 |
Richard Smith <[email protected]> |
Fix regression in bdad0a1: force rebuilding of StmtExpr nodes in
TreeTransform if the 'dependent' flag would change.
|
|
Revision tags: llvmorg-10.0.0-rc3 |
|
| #
bdad0a1b |
| 03-Mar-2020 |
Richard Smith <[email protected]> |
PR45083: Mark statement expressions as being dependent if they appear in
dependent contexts.
We previously assumed they were neither value- nor
instantiation-dependent under any circumstances, which
PR45083: Mark statement expressions as being dependent if they appear in
dependent contexts.
We previously assumed they were neither value- nor
instantiation-dependent under any circumstances, which would lead to
crashes and other misbehavior.
show more ...
|
|
Revision tags: 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, 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 |
|
| #
94bc88eb |
| 17-Jun-2019 |
Richard Smith <[email protected]> |
Fix crash when checking a dependently-typed reference that is
initialized from a non-value-dependent initializer.
llvm-svn: 363622
|
|
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, llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1, llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1, llvmorg-3.8.1, llvmorg-3.8.1-rc1, llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1, llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1, llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3, llvmorg-3.7.0-rc2, llvmorg-3.7.0-rc1, llvmorg-3.6.2, llvmorg-3.6.2-rc1, llvmorg-3.6.1, llvmorg-3.6.1-rc1, llvmorg-3.5.2, llvmorg-3.5.2-rc1, llvmorg-3.6.0, llvmorg-3.6.0-rc4, llvmorg-3.6.0-rc3, llvmorg-3.6.0-rc2, llvmorg-3.6.0-rc1, llvmorg-3.5.1, llvmorg-3.5.1-rc2, llvmorg-3.5.1-rc1, llvmorg-3.5.0, llvmorg-3.5.0-rc4, llvmorg-3.5.0-rc3, llvmorg-3.5.0-rc2, llvmorg-3.5.0-rc1, llvmorg-3.4.2, llvmorg-3.4.2-rc1, llvmorg-3.4.1, llvmorg-3.4.1-rc2, llvmorg-3.4.1-rc1, llvmorg-3.4.0, llvmorg-3.4.0-rc3 |
|
| #
c275da6a |
| 06-Dec-2013 |
Richard Smith <[email protected]> |
PR18152: When computing the semantic form for an initializer list, keep track
of whether the initializer list is dependent.
llvm-svn: 196558
|
|
Revision tags: llvmorg-3.4.0-rc2 |
|
| #
e934d7c9 |
| 21-Nov-2013 |
Richard Smith <[email protected]> |
PR10837: Warn if a null pointer constant is formed by a zero integer constant
expression that is not a zero literal, in C. This is a different, and more
targeted, approach than that in r194540.
llvm
PR10837: Warn if a null pointer constant is formed by a zero integer constant
expression that is not a zero literal, in C. This is a different, and more
targeted, approach than that in r194540.
llvm-svn: 195303
show more ...
|
|
Revision tags: llvmorg-3.4.0-rc1 |
|
| #
71271083 |
| 19-Sep-2013 |
Eli Friedman <[email protected]> |
Fix crash with cast of value-dependent expr.
We don't really need to perform semantic analysis on the dependent expression
anyway, so just call the cast dependent.
<rdar://problem/15012610>
llvm-s
Fix crash with cast of value-dependent expr.
We don't really need to perform semantic analysis on the dependent expression
anyway, so just call the cast dependent.
<rdar://problem/15012610>
llvm-svn: 190981
show more ...
|
|
Revision tags: llvmorg-3.3.1-rc1, llvmorg-3.3.0, llvmorg-3.3.0-rc3, llvmorg-3.3.0-rc2, llvmorg-3.3.0-rc1, llvmorg-3.2.0, llvmorg-3.2.0-rc3, llvmorg-3.2.0-rc2, llvmorg-3.2.0-rc1 |
|
| #
c6e68daa |
| 19-Oct-2012 |
Andy Gibbs <[email protected]> |
Prior to adding the new "expected-no-diagnostics" directive to VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive.
llvm-svn: 1
Prior to adding the new "expected-no-diagnostics" directive to VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive.
llvm-svn: 166280
show more ...
|
|
Revision tags: llvmorg-3.1.0, llvmorg-3.1.0-rc3, llvmorg-3.1.0-rc2, llvmorg-3.1.0-rc1, llvmorg-3.0.0, llvmorg-3.0.0-rc4, llvmorg-3.0.0-rc3, llvmorg-3.0.0-rc2, llvmorg-3.0.0-rc1, llvmorg-2.9.0, llvmorg-2.9.0-rc3, llvmorg-2.9.0-rc2, llvmorg-2.9.0-rc1 |
|
| #
b14dbd73 |
| 21-Dec-2010 |
Douglas Gregor <[email protected]> |
Don't try to compute the value of a value-dependent expression when
checking trivial comparisons. Fixes PR8795.
llvm-svn: 122322
|
| #
4cec5f80 |
| 30-Nov-2010 |
John McCall <[email protected]> |
Fix another case of giving the wrong value kind to a dependent cast to
a non-dependent type.
llvm-svn: 120384
|
| #
29ac8e2e |
| 26-Nov-2010 |
John McCall <[email protected]> |
For internal consistency's sake, compute the value kind of a dependent cast
based on the known properties of the casted-to type. Fixes a crash on spirit.
llvm-svn: 120180
|
|
Revision tags: llvmorg-2.8.0, llvmorg-2.8.0-rc3, llvmorg-2.8.0-rc2, llvmorg-2.8.0-rc1, llvmorg-2.8.0-rc0 |
|
| #
6b197e06 |
| 27-Jul-2010 |
Eli Friedman <[email protected]> |
PR7724: Don't try to evaluate value-dependent expressions.
llvm-svn: 109532
|
| #
024d80e5 |
| 22-May-2010 |
Douglas Gregor <[email protected]> |
Don't look for a destructor in a dependent type. Fixes PR7198.
llvm-svn: 104445
|
|
Revision tags: llvmorg-2.7.0 |
|
| #
5fcb51c0 |
| 15-Jan-2010 |
Douglas Gregor <[email protected]> |
When determining whether a DeclRefExpr is value-dependent when it
references a const variable of integral type, the initializer may be
in a different declaration than the one that name-lookup saw. Fi
When determining whether a DeclRefExpr is value-dependent when it
references a const variable of integral type, the initializer may be
in a different declaration than the one that name-lookup saw. Find the
initializer anyway. Fixes PR6045.
llvm-svn: 93514
show more ...
|