ChuanqiXu9 wrote:
@jansvoboda11 ping. Did my answers resolve your concerns?
https://github.com/llvm/llvm-project/pull/92085
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bra
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/92511
>From 57cfb2b7791666022ee46201b5126ac610c19bdd Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Fri, 17 May 2024 14:25:53 +0800
Subject: [PATCH] [serialization] No transitive type change
---
.../include/clang
ChuanqiXu9 wrote:
@jansvoboda11 @ilya-biryukov would you like to take look?
https://github.com/llvm/llvm-project/pull/92511
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bra
ChuanqiXu9 wrote:
> Thanks for the change! I have done a round of review and left a few
> suggestion and also have a bunch of questions. I am sorry if some of them may
> look too obvious, I did try to dig into the code where I could, but Clang's
> serialization is complicated and some things a
@@ -7100,14 +7084,25 @@ TypeSourceInfo *ASTRecordReader::readTypeSourceInfo() {
return TInfo;
}
+std::pair
+ASTReader::translateTypeIDToIndex(serialization::TypeID ID) const {
+ unsigned Index =
+ (ID & llvm::maskTrailingOnes(32)) >> Qualifiers::FastWidth;
+
+ ModuleF
@@ -70,38 +71,53 @@ using DeclID = DeclIDBase::DeclID;
/// An ID number that refers to a type in an AST file.
///
-/// The ID of a type is partitioned into two parts: the lower
+/// The ID of a type is partitioned into three parts:
+/// - the lower
/// three bits are used to
@@ -6659,13 +6655,22 @@ void ASTWriter::MacroRead(serialization::MacroID ID,
MacroInfo *MI) {
}
void ASTWriter::TypeRead(TypeIdx Idx, QualType T) {
- // Always take the highest-numbered type index. This copes with an
interesting
+ // Always take the type index that comes i
@@ -6659,13 +6655,22 @@ void ASTWriter::MacroRead(serialization::MacroID ID,
MacroInfo *MI) {
}
void ASTWriter::TypeRead(TypeIdx Idx, QualType T) {
- // Always take the highest-numbered type index. This copes with an
interesting
+ // Always take the type index that comes i
@@ -12,44 +12,44 @@
// RUN: -fmodule-file=Module=%t/Module.pcm -emit-llvm -o - | FileCheck
%t/Object.cppm
// Test again with reduced BMI.
-// RUN: rm -rf %t
-// RUN: mkdir -p %t
-// RUN: split-file %s %t
+// RUNX: rm -rf %t
ChuanqiXu9 wrote:
Oh, sorry. T
@@ -7392,27 +7388,28 @@ QualType ASTReader::GetType(TypeID ID) {
return TypesLoaded[Index].withFastQualifiers(FastQuals);
}
-QualType ASTReader::getLocalType(ModuleFile &F, unsigned LocalID) {
+QualType ASTReader::getLocalType(ModuleFile &F, TypeID LocalID) {
---
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/92511
>From 57cfb2b7791666022ee46201b5126ac610c19bdd Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Fri, 17 May 2024 14:25:53 +0800
Subject: [PATCH 1/2] [serialization] No transitive type change
---
.../include/c
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/92511
>From 57cfb2b7791666022ee46201b5126ac610c19bdd Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Fri, 17 May 2024 14:25:53 +0800
Subject: [PATCH 1/2] [serialization] No transitive type change
---
.../include/c
@@ -6659,13 +6655,22 @@ void ASTWriter::MacroRead(serialization::MacroID ID,
MacroInfo *MI) {
}
void ASTWriter::TypeRead(TypeIdx Idx, QualType T) {
- // Always take the highest-numbered type index. This copes with an
interesting
+ // Always take the type index that comes i
@@ -7650,6 +7647,16 @@ ModuleFile *ASTReader::getOwningModuleFile(GlobalDeclID
ID) const {
return &getModuleManager()[ModuleFileIndex - 1];
}
+ModuleFile *ASTReader::getOwningModuleFile(TypeID ID) const {
+ if (ID < NUM_PREDEF_TYPE_IDS)
+return nullptr;
+
+ uint64_t M
@@ -3262,17 +3262,18 @@ void ASTWriter::WritePragmaDiagnosticMappings(const
DiagnosticsEngine &Diag,
/// Write the representation of a type to the AST stream.
void ASTWriter::WriteType(QualType T) {
TypeIdx &IdxRef = TypeIdxs[T];
- if (IdxRef.getIndex() == 0) // we haven't
@@ -70,38 +71,53 @@ using DeclID = DeclIDBase::DeclID;
/// An ID number that refers to a type in an AST file.
///
-/// The ID of a type is partitioned into two parts: the lower
+/// The ID of a type is partitioned into three parts:
+/// - the lower
/// three bits are used to
@@ -70,38 +71,53 @@ using DeclID = DeclIDBase::DeclID;
/// An ID number that refers to a type in an AST file.
///
-/// The ID of a type is partitioned into two parts: the lower
+/// The ID of a type is partitioned into three parts:
+/// - the lower
/// three bits are used to
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83233
error: too big or took too long to generate
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/ll
ChuanqiXu9 wrote:
Sorry for bothering, I tried a new manner to update the patch but it shows I
should better : (
https://github.com/llvm/llvm-project/pull/83237
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83233
>From 2bf5a6ca8bde003b7acf0a9ab7c6e69cc3109e02 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH] [Serialization] Introduce OnDiskHashTable for specializations
Fo
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83237
>From f2e53e44eebab4720a1dbade24fcb14d698fb03f Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH] [Serialization] Code cleanups and polish 83233
---
clang/includ
ChuanqiXu9 wrote:
@ilya-biryukov I've fixed the crash occured in the reproducer. The root reason
is that, previously, I wouldn't load all the specializations for paritial
specializations. But this is not safe. I think you can test it again.
https://github.com/llvm/llvm-project/pull/83237
_
ChuanqiXu9 wrote:
@vgvassilev In the newest version, I introduced a new hasher
TemplateArgumentHasher and use this new hasher to calculate the hash value for
template arguments. We thought this may be harder. But I just realized, we
don't have to provide a very precise results at first. Since
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83237
>From f2e53e44eebab4720a1dbade24fcb14d698fb03f Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH 1/2] [Serialization] Code cleanups and polish 83233
---
clang/in
ChuanqiXu9 wrote:
> > > @ilya-biryukov, could we have another try of this PR on your end?
> >
> >
> > Sorry for missing this, we will rerun the testing and get back to you.
>
> In the meantime, could you rebase the patch on top of current ToT?
Are you saying to rebase on your local branch? Si
ChuanqiXu9 wrote:
> We've hit an error during testing:
>
> ```c++
> In module '...stl_cc_library':
> .../src/libcxx/include/__memory/allocator.h:128:60: error:
> 'std::allocator>::deallocate' from
> module '...stl_cc_library./cxx17/vector' is not present in definition of
> 'std::allocator>' p
ChuanqiXu9 wrote:
I feel this is good and no risks to bring in 19.x
https://github.com/llvm/llvm-project/pull/102159
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-com
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/99283
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -1455,6 +1462,62 @@ struct SwitchCoroutineSplitter {
setCoroInfo(F, Shape, Clones);
}
+ static Function *createNoAllocVariant(Function &F, coro::Shape &Shape,
+SmallVectorImpl &Clones) {
+auto *OrigFnTy = F.getFunctionType(
@@ -1455,6 +1462,64 @@ struct SwitchCoroutineSplitter {
setCoroInfo(F, Shape, Clones);
}
+ static Function *createNoAllocVariant(Function &F, coro::Shape &Shape,
+SmallVectorImpl &Clones) {
+auto *OrigFnTy = F.getFunctionType(
@@ -63,6 +63,13 @@ suspend:
; CHECK-NOT: call void @free(
; CHECK: ret void
+; CHECK-LABEL: @f.noalloc({{.*}})
ChuanqiXu9 wrote:
I think it worth to list the arguments explicitly.
https://github.com/llvm/llvm-project/pull/99283
__
@@ -1967,22 +2047,13 @@ splitCoroutine(Function &F, SmallVectorImpl
&Clones,
for (DbgVariableRecord *DVR : DbgVariableRecords)
coro::salvageDebugInfo(ArgToAllocaMap, *DVR, Shape.OptimizeFrame,
false /*UseEntryValue*/);
- return Shape;
-}
-//
https://github.com/ChuanqiXu9 commented:
We need to update coroutines.rst for such changes.
https://github.com/llvm/llvm-project/pull/99283
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
@@ -5,7 +5,7 @@
define nonnull ptr @f(i32 %n) presplitcoroutine {
; CHECK-LABEL: @f(
; CHECK-NEXT: entry:
-; CHECK-NEXT:[[ID:%.*]] = call token @llvm.coro.id(i32 0, ptr null, ptr
null, ptr @f.resumers)
+; CHECK-NEXT:[[ID:%.*]] = call token @llvm.coro.id(i32 0, ptr nul
@@ -1455,6 +1462,62 @@ struct SwitchCoroutineSplitter {
setCoroInfo(F, Shape, Clones);
}
+ static Function *createNoAllocVariant(Function &F, coro::Shape &Shape,
ChuanqiXu9 wrote:
We need comment and an example for this function
https://github.com/llv
https://github.com/ChuanqiXu9 commented:
I did a quick scanning and I'll put the comment in
https://github.com/llvm/llvm-project/pull/99283#pullrequestreview-822800
https://github.com/llvm/llvm-project/pull/99285
___
llvm-branch-commits mailing li
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/99285
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -0,0 +1,136 @@
+//===- CoroSplit.cpp - Converts a coroutine into a state machine
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
ChuanqiXu9 wrote:
After I took a quick look at https://github.com/llvm/llvm-project/pull/99285, I
feel this is not what I thought when I heard the idea. Correct me if I
misunderstand it.
The problems are:
1. It looks like all the `.noalloc` variant are emitted all the time. This is
absolutely
@@ -1455,6 +1462,62 @@ struct SwitchCoroutineSplitter {
setCoroInfo(F, Shape, Clones);
}
+ static Function *createNoAllocVariant(Function &F, coro::Shape &Shape,
+SmallVectorImpl &Clones) {
+auto *OrigFnTy = F.getFunctionType(
@@ -5,7 +5,7 @@
define nonnull ptr @f(i32 %n) presplitcoroutine {
; CHECK-LABEL: @f(
; CHECK-NEXT: entry:
-; CHECK-NEXT:[[ID:%.*]] = call token @llvm.coro.id(i32 0, ptr null, ptr
null, ptr @f.resumers)
+; CHECK-NEXT:[[ID:%.*]] = call token @llvm.coro.id(i32 0, ptr nul
ChuanqiXu9 wrote:
I landed this directly as the owner of serialization. I feel this change is not
riskful as it adds more conditions to generate a diagnose message we didn't do
in 18.x and before. So nothing will be worse.
https://github.com/llvm/llvm-project/pull/102425
__
ChuanqiXu9 wrote:
> @ChuanqiXu9 are we good to merge this? It seems like a pretty big patch but
> reading the description it seems like some good fixes in there. Any risk
> taking this on?
Yes, this is not small. And I am 100% sure it is fine. But given this is
important, I still like to back
ChuanqiXu9 wrote:
> > How about waiting 2 weeks to see if there is any regression reports? If no,
> > I'll try to ping you again to merge this.
>
> That seems counter-intuitive. Yes there are projects using LLVM main, but it
> would appear much more likely to me to get regression reports from
https://github.com/ChuanqiXu9 milestoned
https://github.com/llvm/llvm-project/pull/102438
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
ChuanqiXu9 wrote:
> @ChuanqiXu9, is there anything else that needs to be done here? There's a
> merge conflict; I could resolve that.
If there is merge conflict, we need to resolve it. For the merge request, we
need to wait for the release manager to have a time to look at this. Maybe due
to
ChuanqiXu9 wrote:
Although we announced that the support for C++20 modules in clangd is broken,
there are already a lot of people tried to use clangd with modules in some
level. So it should be helpful to backport this to clang18 as well to improve
the user experience as much as possible.
htt
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/83233
Following up for https://github.com/llvm/llvm-project/pull/83108
This follows the suggestion literally from
https://github.com/llvm/llvm-project/pull/76774#issuecomment-1951172457
which introduces OnDiskHashT
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/83233
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
ChuanqiXu9 wrote:
> Can you rebase on top of #83108 ? That'd make it easier for me to review.
Weird. It should be on top of #83108 already.
https://github.com/llvm/llvm-project/pull/83233
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.
ChuanqiXu9 wrote:
> > > Can you rebase on top of #83108 ? That'd make it easier for me to review.
> >
> >
> > Weird. It should be on top of #83108 already.
> > https://github.com/llvm/llvm-project/commits/users/ChuanqiXu9/D41416_on_disk_hash_table/
>
> Ah, it is a single commit that includes
ChuanqiXu9 wrote:
> If that's ready to give it a try on our infrastructure I can do it.
I'll try to update the polishing patch. While it might purely be removing
codes, I think it may be better to test on that.
https://github.com/llvm/llvm-project/pull/83233
___
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/83237
This is the following of https://github.com/llvm/llvm-project/pull/83233. This
simply removes `LazySpecializationInfo` from `RedeclarableTemplateDecl`. I
feel it can make the review process much more easier
@@ -257,22 +241,12 @@ namespace clang {
// If we have any lazy specializations, and the external AST source is
// our chained AST reader, we can just write out the DeclIDs. Otherwise,
// we need to resolve them to actual declarations.
- if (Writer.Chain !
ChuanqiXu9 wrote:
@vgvassilev this may be ready to test.
https://github.com/llvm/llvm-project/pull/83237
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/83237
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
ChuanqiXu9 wrote:
The error message looks odd since the language options shouldn't be involved.
https://github.com/llvm/llvm-project/pull/83237
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailm
ChuanqiXu9 wrote:
> > The error message looks odd since the language options shouldn't be
> > involved.
>
> Sorry, I did not push. Now you can take a look.
I mean your local results.
https://github.com/llvm/llvm-project/pull/83237
___
llvm-branch-co
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83233
>From 03e7d56b79531d2e964d85e5bec52ccd6c6422e7 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH] [Serialization] Introduce OnDiskHashTable for specializations
Fo
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83237
>From 19617bbdd5b83076140af087d3da0b46d4fe0208 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH] [Serialization] Code cleanups and polish 83233
---
clang/includ
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83237
>From 1d288e76b213a25d15fa6abdf633488838ed100a Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH] [Serialization] Code cleanups and polish 83233
---
clang/includ
ChuanqiXu9 wrote:
@ilya-biryukov hi, the functional and performance test on the root side looks
good: https://github.com/root-project/root/pull/14495#issuecomment-1980589145
Could you try to test this within google internals?
Also if your projects implements new ExternalASTSource, you need to
https://github.com/ChuanqiXu9 milestoned
https://github.com/llvm/llvm-project/pull/84723
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/84723
Backport 3f6bc1adf805681293c2ef0b93b708ff52244c00
This fixes a surprising regression introduced in
https://github.com/llvm/llvm-project/issues/79240. Given we've backported that
to 18.x. We need to backport
ChuanqiXu9 wrote:
@tstellar Could we backport this to 18.x?
https://github.com/llvm/llvm-project/pull/84723
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/85637
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
ChuanqiXu9 wrote:
Yeah, agreed.
https://github.com/llvm/llvm-project/pull/85637
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83233
>From f87a54e8ae2afc807cb275f5763691e06562ab0a Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH] [Serialization] Introduce OnDiskHashTable for specializations
Fo
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83237
>From 40012e175a6ab3420e2dcaa64538b210173d6950 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH 1/2] [Serialization] Code cleanups and polish 83233
---
clang/in
ChuanqiXu9 wrote:
Thanks for the reduced test case. It is pretty helpful. I've added it to the
current patch.
The root cause of the issue comes from an oversight in
https://github.com/llvm/llvm-project/pull/83108/files#diff-dffd10772d07fb8c737cdf812839afa0173447c4812698c0c19618c34d92daddR806-R
ChuanqiXu9 wrote:
> Sorry, still struggling to get a small repro. The build graphs we have are
> quite large, unfortunately. Did any of the stack traces or error message I
> posted help to find certain problems? Or is there no hope until we get a
> smaller repro?
I tried to review the patch p
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83233
>From 80c9ab1d56e1e69407af75444f276df446008fed Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH] [Serialization] Introduce OnDiskHashTable for specializations
Fo
ChuanqiXu9 wrote:
Rebased with main
https://github.com/llvm/llvm-project/pull/83233
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83237
>From f4edc5b1cde1735d1c9c9f6c43ef4f50066965b0 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH 1/2] [Serialization] Code cleanups and polish 83233
---
clang/in
ChuanqiXu9 wrote:
Rebased with main
https://github.com/llvm/llvm-project/pull/83237
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/92085
Following of https://github.com/llvm/llvm-project/pull/92083
The motivation is still cutting of the unnecessary change in the dependency
chain. See the above link (recursively) for details.
After this patch,
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/92085
>From c612b56dec8bfc7c1612e94be8876316f14ea8ea Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Tue, 14 May 2024 15:33:12 +0800
Subject: [PATCH] [Serialization] No transitive identifier change
---
.../clang/L
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/92511
Following of https://github.com/llvm/llvm-project/pull/92085.
motivation
The motivation is still cutting of the unnecessary change in the dependency
chain. See the above link (recursively) for details.
ChuanqiXu9 wrote:
@jansvoboda11 @Bigcheese gentle ping
https://github.com/llvm/llvm-project/pull/92085
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
ChuanqiXu9 wrote:
@jansvoboda11 @Bigcheese gentle ping
https://github.com/llvm/llvm-project/pull/92511
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/92085
>From a2fb7f50161932a9557a22a4ba23f827e80a4d6b Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Tue, 14 May 2024 15:33:12 +0800
Subject: [PATCH] [Serialization] No transitive identifier change
---
.../clang/L
@@ -124,7 +124,7 @@ struct HeaderFileInfo {
/// This ID number will be non-zero when there is a controlling
/// macro whose IdentifierInfo may not yet have been loaded from
/// external storage.
- unsigned ControllingMacroID = 0;
+ uint64_t ControllingMacroID = 0;
-
@@ -918,7 +918,7 @@ ASTSelectorLookupTrait::ReadKey(const unsigned char* d,
unsigned) {
SelectorTable &SelTable = Reader.getContext().Selectors;
unsigned N = endian::readNext(d);
const IdentifierInfo *FirstII = Reader.getLocalIdentifier(
- F, endian::readNext(d));
+
@@ -3896,7 +3903,7 @@ void ASTWriter::WriteIdentifierTable(Preprocessor &PP,
// Write out identifiers if either the ID is local or the identifier has
// changed since it was loaded.
- if (ID >= FirstIdentID || !Chain || !II->isFromAST() ||
+ if (isLocalId
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/92511
>From 1a83e2b0f00183c61e7a5303ea7eeb0b279c7e91 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Fri, 17 May 2024 14:25:53 +0800
Subject: [PATCH] [serialization] No transitive type change
---
.../include/clang
Author: Chuanqi Xu
Date: 2023-09-18T15:09:00+08:00
New Revision: 88bf774c565080e30e0a073676c316ab175303af
URL:
https://github.com/llvm/llvm-project/commit/88bf774c565080e30e0a073676c316ab175303af
DIFF:
https://github.com/llvm/llvm-project/commit/88bf774c565080e30e0a073676c316ab175303af.diff
LO
Author: Chuanqi Xu
Date: 2023-09-18T15:05:07+08:00
New Revision: 2cfdebdb7e5e430471ea833b33eee72c1938eb98
URL:
https://github.com/llvm/llvm-project/commit/2cfdebdb7e5e430471ea833b33eee72c1938eb98
DIFF:
https://github.com/llvm/llvm-project/commit/2cfdebdb7e5e430471ea833b33eee72c1938eb98.diff
LO
@@ -17,38 +17,17 @@ module;
// The headers of Table 24: C++ library headers [tab:headers.cpp]
// and the headers of Table 25: C++ headers for C library facilities
[tab:headers.cpp.c]
-#include
-#include
-#include
-#if !defined(_LIBCPP_HAS_NO_ATOMIC_HEADER)
-# include
-#e
@@ -17,38 +17,17 @@ module;
// The headers of Table 24: C++ library headers [tab:headers.cpp]
// and the headers of Table 25: C++ headers for C library facilities
[tab:headers.cpp.c]
-#include
-#include
-#include
-#if !defined(_LIBCPP_HAS_NO_ATOMIC_HEADER)
-# include
-#e
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/77417
This is the successor of https://github.com/llvm/llvm-project/pull/76774.
I meant to use spr but I failed. So I created the stacked review here manually.
Hope this won't be too bad.
The core idea of the patc
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/77417
>From 23184b26934c5a3ba833fb3d7a12adcafb6fad8e Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Thu, 4 Jan 2024 16:19:05 +0800
Subject: [PATCH] Load Specialization Updates Lazily
---
.../include/clang/Seriali
ChuanqiXu9 wrote:
> @ChuanqiXu9, I managed to push the commit here back to #76774 and we can
> continue the discussion there. Would that be sufficient?
The intention of split the patch is to ease the reviewing. If you are glad to
do that, yes, it will be pretty good : )
https://github.com/llv
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/77417
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
ChuanqiXu9 wrote:
Then this is not needed as far as I understood.
https://github.com/llvm/llvm-project/pull/77417
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit
@@ -131,13 +138,65 @@ def parseScript(test, preamble):
script += preamble
script += scriptInTest
+has_std_module = False
+has_std_compat_module = False
+for module in modules:
+if module == "std":
+has_std_module = True
+elif mod
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/80249
The backport follows the new practice suggested in
https://discourse.llvm.org/t/release-18-x-branch-has-been-created/76480.
See https://github.com/llvm/llvm-project/issues/79240 and
https://github.com/llvm/l
https://github.com/ChuanqiXu9 milestoned
https://github.com/llvm/llvm-project/pull/80249
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/80249
>From 85dc0ff79515cc439cc3e0d8c991709ad789a50b Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Mon, 29 Jan 2024 11:42:08 +0800
Subject: [PATCH 1/3] [C++20] [Modules] Don't perform ODR checks in GMF
Close http
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/80249
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83237
>From f2e53e44eebab4720a1dbade24fcb14d698fb03f Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH 1/3] [Serialization] Code cleanups and polish 83233
---
clang/in
1 - 100 of 167 matches
Mail list logo
