falbrechtskirchinger wrote:
> @falbrechtskirchinger Ooops, yes, it's true that the bug is gone w/ #79.
>
> But I'd say if we're going to cherry-pick #79, we have to backport its
> precedent #103867 as well, so I think we can probably go ahead with this one
> and backport it to 19, and
falbrechtskirchinger wrote:
@zyn0217 #79 has fixed this crash as well. Should I strip this PR down to
the unit test, or does it still make sense to you, to keep the changes?
> Will this be backported to 19.x afterwards?
I was also going to ask, though, it's now a question about #79.
h
falbrechtskirchinger wrote:
> So yes, this one is still necessary - it should occur with an
> assertion-enabled build when compiling a header containing an invalid concept
> decl.
Not in my testing.
https://github.com/llvm/llvm-project/pull/110496
___
@@ -1899,7 +1899,7 @@ void
ASTDeclWriter::VisitTemplateTypeParmDecl(TemplateTypeParmDecl *D) {
Record.push_back(D->wasDeclaredWithTypename());
const TypeConstraint *TC = D->getTypeConstraint();
- assert((bool)TC == D->hasTypeConstraint());
+ Record.push_back(/*TypeConst
@@ -2674,7 +2674,7 @@ void
ASTDeclReader::VisitTemplateTypeParmDecl(TemplateTypeParmDecl *D) {
D->setDeclaredWithTypename(Record.readInt());
- if (D->hasTypeConstraint()) {
+ if (Record.readBool() && D->hasTypeConstraint()) {
falbrechtskirchinger wrote:
https://github.com/falbrechtskirchinger updated
https://github.com/llvm/llvm-project/pull/110496
>From 220d76a2b2327318a6b5261896736ddd3f05988a Mon Sep 17 00:00:00 2001
From: Florian Albrechtskirchinger
Date: Mon, 30 Sep 2024 12:58:15 +0200
Subject: [PATCH] [Serialization] Handle uninitialized
falbrechtskirchinger wrote:
> Bump, it would be nice to have this or that fix backported to 19.x
@vient Backport is happening. #113182
https://github.com/llvm/llvm-project/pull/110496
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lis
https://github.com/falbrechtskirchinger created
https://github.com/llvm/llvm-project/pull/113137
Add a test case for the assertion error encountered in #99036 and #109354. The
issue was incidentally fixed by #79.
>From a19b65b8512b103afae697cadf1ccd7cce4ef940 Mon Sep 17 00:00:00 2001
From:
falbrechtskirchinger wrote:
@cor3ntin @zyn0217, please review. This is just the test case from #110496.
Thanks!
https://github.com/llvm/llvm-project/pull/113137
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
falbrechtskirchinger wrote:
> I think the best past forward would be to close this PR, and to open a new
> one targeting the 10.x branch, which a clear explanation that it's not needed
> in trunk. would that work for you @falbrechtskirchinger ?
Will do.
https://github.com/llvm/llvm-project/pu
https://github.com/falbrechtskirchinger closed
https://github.com/llvm/llvm-project/pull/110496
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/falbrechtskirchinger updated
https://github.com/llvm/llvm-project/pull/110496
>From 8913503b3fd5518201663395d91b7444232e9856 Mon Sep 17 00:00:00 2001
From: Florian Albrechtskirchinger
Date: Mon, 30 Sep 2024 12:58:15 +0200
Subject: [PATCH] [clangd][AST] Handle uninitialized ty
falbrechtskirchinger wrote:
> Thanks again for analyzing & working on this issue.
You’re very welcome! Let's hope I'm on the right track.
> Some suggestions regarding the test:
>
> 1. As this is more of a clang issue (the offending code belongs to the
> serialization part of clang), so it
https://github.com/falbrechtskirchinger edited
https://github.com/llvm/llvm-project/pull/110496
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/falbrechtskirchinger created
https://github.com/llvm/llvm-project/pull/110496
Note: This patch is based on the assumption, that an assertion causing a crash
in clangd, is incorrect. Alternatively, the true error may lie elsewhere,
possibly in ´Sema::BuildTypeConstraint`/`Sem
@@ -1899,7 +1899,7 @@ void
ASTDeclWriter::VisitTemplateTypeParmDecl(TemplateTypeParmDecl *D) {
Record.push_back(D->wasDeclaredWithTypename());
const TypeConstraint *TC = D->getTypeConstraint();
- assert((bool)TC == D->hasTypeConstraint());
+ Record.push_back(TC != nullp
https://github.com/falbrechtskirchinger updated
https://github.com/llvm/llvm-project/pull/110496
>From 20042cc1b4ada2065813e118c24236a61e83d1a9 Mon Sep 17 00:00:00 2001
From: Florian Albrechtskirchinger
Date: Mon, 30 Sep 2024 12:58:15 +0200
Subject: [PATCH] [clangd] [AST] Handle uninitialized t
https://github.com/falbrechtskirchinger updated
https://github.com/llvm/llvm-project/pull/110496
>From c090601a032c6ba406928821ec4296d190edade5 Mon Sep 17 00:00:00 2001
From: Florian Albrechtskirchinger
Date: Mon, 30 Sep 2024 12:58:15 +0200
Subject: [PATCH] [clangd][AST] Handle uninitialized ty
falbrechtskirchinger wrote:
> We need to resort to `-fallow-pch-with-compiler-errors` :)
Ah, thanks! I would not have figured that out on my own. :)
> Specifically, add the following file to `clang/test/PCH` (or somehow merge it
> into a pre-existing test, which I'd prefer)
I looked through t
@@ -27,3 +25,12 @@ int main() {
}
#endif
+
+namespace GH99036 {
+
+template
+concept C; // expected-error {{expected '='}}
+// expected-note@32 {{declared here}}
falbrechtskirchinger wrote:
Should have used `@-1` here.
https://github.com/llvm/llvm-project/p
20 matches
Mail list logo
