ChuanqiXu9 wrote:
> Can we add a release note and documentation for this? Thanks!
The current patch is transparent to users and it is only part of the series
patches. I'd like to document that after I made the series of patches.
https://github.com/llvm/llvm-project/pull/75894
Author: Chuanqi Xu
Date: 2024-03-06T15:46:55+08:00
New Revision: d3df2a834cf6febb44c699d109b9e7f622194837
URL:
https://github.com/llvm/llvm-project/commit/d3df2a834cf6febb44c699d109b9e7f622194837
DIFF:
https://github.com/llvm/llvm-project/commit/d3df2a834cf6febb44c699d109b9e7f622194837.diff
ChuanqiXu9 wrote:
I am going to land this in the week later if no objections come in. I think it
is necessary to land the series of patches (to reduce the contents of BMI) for
clang19. And of course, the functionality will be opt in for one~two releases
for experimental.
ChuanqiXu9 wrote:
> Do you expect to make any changes to type streaming?
I don't expect to do that explicitly. The number of types deserialized can be
decreased naturally after we avoid emitting declarations during the writing.
https://github.com/llvm/llvm-project/pull/75894
@@ -830,6 +843,19 @@ class PCHGenerator : public SemaConsumer {
bool hasEmittedPCH() const { return Buffer->IsComplete; }
};
+class ReducedBMIGenerator : public PCHGenerator {
+public:
+ ReducedBMIGenerator(const Preprocessor , InMemoryModuleCache ,
+
ChuanqiXu9 wrote:
> * I do not want to block progress, so let's move forward with this patch for
> now.
Yeah. Great to see we have some progress finally. I think this is really
important since I see more and more peope complaninig the performance for
modules. I feel this series patch is key
ChuanqiXu9 wrote:
> Thank you for references both.
>
> Actually, I'd like to have PR like #83961. Is it acceptable to merge this
> kind of PR in that case then?
I don't feel the patches are related. I think you can only format the changed
lines.
ChuanqiXu9 wrote:
Oh, I found it here: https://llvm.org/docs/CodingStandards.html#introduction
> Our long term goal is for the entire codebase to follow the convention, but
> we explicitly do not want patches that do large-scale reformatting of
> existing code.
ChuanqiXu9 wrote:
I remember we have policies that we don't like patches which purely formats
codes. It makes backporting and cherry-picking harder. But I can't find the
wording now.
CC: @AaronBallman @Endilll
https://github.com/llvm/llvm-project/pull/83974
https://github.com/ChuanqiXu9 commented:
Thanks. This looks good to me except few nit comments.
Have you tested on a real world workloads?
https://github.com/llvm/llvm-project/pull/79712
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -167,6 +167,53 @@ class CoroCloner {
} // end anonymous namespace
+// FIXME:
+// Lower the intrinisc in CoroEarly phase if coroutine frame doesn't escape
+// and it is known that other transformations, for example, sanitizers
+// won't lead to incorrect code.
+static void
@@ -338,6 +414,71 @@ static QualType getCoroutineSuspendExprReturnType(const
ASTContext ,
}
#endif
+llvm::Function *
+CodeGenFunction::generateAwaitSuspendWrapper(Twine const ,
+ Twine const ,
+
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/79712
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -72,6 +72,10 @@ sections with improvements to Clang's support for those
languages.
C++ Language Changes
+C++14 Feature Support
+^
+- Sized deallocation is enabled by default in C++14 onwards.
ChuanqiXu9 wrote:
It
@@ -0,0 +1,44 @@
+//===--- SizedDellocation.h - Sized Deallocation *- C++
-*-===//
+//
+// 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:
ChuanqiXu9 wrote:
@mordante if we want this for 18, we need to land and backport it in this week.
https://github.com/llvm/llvm-project/pull/82160
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
ChuanqiXu9 wrote:
> That'd mean that we "just" need to replace LazySpecializationInfo
> *LazySpecializations = nullptr; with the on-disk hash table approach. That
> would probably require centralizing that logic somewhere in the ASTReader
> (the way this PR does) but with minimal changes wrt
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83108
>From 59e1880df74434e3c446705788d92b5949d99536 Mon Sep 17 00:00:00 2001
From: Vassil Vassilev
Date: Sun, 7 Jan 2018 15:16:11 +0200
Subject: [PATCH 1/3] D41416: [modules] [pch] Do not deserialize all lazy
ChuanqiXu9 wrote:
Weird. I only see two failures in my local environment:
```
Failed Tests (2):
Clang :: Modules/cxx-templates.cpp
Clang :: Modules/odr_hash.cpp
```
And I saw both of them in my patch. It is simply order mismatches.
https://github.com/llvm/llvm-project/pull/83108
ChuanqiXu9 wrote:
Oh, I didn't notice you've removed D153003 already. But the branch name looks
not good. So I've created a pr in
https://github.com/llvm/llvm-project/pull/83108
https://github.com/llvm/llvm-project/pull/76774
___
cfe-commits mailing
ChuanqiXu9 wrote:
Personally I feel this patch is good and the testing result from our workload
shows it is good too. But it looks like the performance testing results from
google @zygoloid @ilya-biryukov is not good. So maybe we need to wait for
landing this. (It will be great if
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/83108
This from https://reviews.llvm.org/D41416. And we plan to introduce on disk
hash table based on this. See https://github.com/llvm/llvm-project/pull/76774.
Following off are cited from
ChuanqiXu9 wrote:
@rjmccall @dwblaikie
https://github.com/llvm/llvm-project/pull/75912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -41,7 +41,7 @@ void TestCatch2() {
try {
}
// CHECK-NEXT:CXXCatchStmt
-// CHECK-NEXT: NULL
+// CHECK-NEXT: VarDecl {{.*}} ''
ChuanqiXu9 wrote:
Maybe we can improve to print this.
https://github.com/llvm/llvm-project/pull/80976
@@ -1053,6 +1053,10 @@ class VarDecl : public DeclaratorDecl, public
Redeclarable {
LLVM_PREFERRED_TYPE(bool)
unsigned ExceptionVar : 1;
+/// To Check the ellipsis
+LLVM_PREFERRED_TYPE(bool)
+unsigned EllipsisVar : 1;
ChuanqiXu9 wrote:
@@ -16983,7 +16983,7 @@ VarDecl *Sema::BuildExceptionDeclaration(Scope *S,
/// ActOnExceptionDeclarator - Parsed the exception-declarator in a C++ catch
/// handler.
-Decl *Sema::ActOnExceptionDeclarator(Scope *S, Declarator ) {
+Decl *Sema::ActOnExceptionDeclarator(Scope *S,
@@ -1053,6 +1053,10 @@ class VarDecl : public DeclaratorDecl, public
Redeclarable {
LLVM_PREFERRED_TYPE(bool)
unsigned ExceptionVar : 1;
+/// To Check the ellipsis
ChuanqiXu9 wrote:
The comment is not clear
@@ -2698,9 +2698,16 @@ StmtResult Parser::ParseCXXCatchBlock(bool FnCatch) {
Declarator ExDecl(DS, Attributes, DeclaratorContext::CXXCatch);
ParseDeclarator(ExDecl);
ExceptionDecl = Actions.ActOnExceptionDeclarator(getCurScope(), ExDecl);
- } else
-
@@ -271,6 +271,9 @@ void TextNodeDumper::Visit(const Decl *D) {
OS << " hidden";
if (D->isImplicit())
OS << " implicit";
+ if (const VarDecl *ND = dyn_cast(D))
+ if (ND->isEllipsisVariable())
+ OS << " catch_all";
ChuanqiXu9 wrote:
ditto
@@ -115,6 +115,10 @@ void JSONNodeDumper::Visit(const Decl *D) {
else if (D->isThisDeclarationReferenced())
JOS.attribute("isReferenced", true);
+ if (const VarDecl *ND = dyn_cast(D))
+ if (ND->isEllipsisVariable())
+ JOS.attribute("catch_all", true);
@@ -1474,6 +1478,16 @@ class VarDecl : public DeclaratorDecl, public
Redeclarable {
NonParmVarDeclBits.ExceptionVar = EV;
}
+ /// Determine the Ellipsis (...) or not
+ bool isEllipsisVariable() const {
+return isa(this) ? false : NonParmVarDeclBits.EllipsisVar;
+
https://github.com/ChuanqiXu9 commented:
+1 that we should reduce the impact of the patch as much as possible.
Also every time we change the data member of decls and stmts, we need to update
the serialization part.
https://github.com/llvm/llvm-project/pull/80976
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/80976
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 approved this pull request.
https://github.com/llvm/llvm-project/pull/82773
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Chuanqi Xu
Date: 2024-02-23T16:54:13+08:00
New Revision: b014944e47ba6e2031e968268b15fba43a9e1dbf
URL:
https://github.com/llvm/llvm-project/commit/b014944e47ba6e2031e968268b15fba43a9e1dbf
DIFF:
https://github.com/llvm/llvm-project/commit/b014944e47ba6e2031e968268b15fba43a9e1dbf.diff
Author: Chuanqi Xu
Date: 2024-02-23T11:05:15+08:00
New Revision: 2e5af56b05c2d39ab2c829bf4c13190523b67ddd
URL:
https://github.com/llvm/llvm-project/commit/2e5af56b05c2d39ab2c829bf4c13190523b67ddd
DIFF:
https://github.com/llvm/llvm-project/commit/2e5af56b05c2d39ab2c829bf4c13190523b67ddd.diff
ChuanqiXu9 wrote:
> > > > Let's zoom out a little. The approach in D41416 shows that it is
> > > > feasible to store _a_ hash of the template arguments to delay eager
> > > > deserializations. The ODR hash approach is a second order problem
> > > > because we can swap it with something better
Author: Chuanqi Xu
Date: 2024-02-20T14:33:48+08:00
New Revision: 96e56573089b2a211c71660b0ffc7deb21049bdd
URL:
https://github.com/llvm/llvm-project/commit/96e56573089b2a211c71660b0ffc7deb21049bdd
DIFF:
https://github.com/llvm/llvm-project/commit/96e56573089b2a211c71660b0ffc7deb21049bdd.diff
ChuanqiXu9 wrote:
I'd like to close this since the issue got closed.
https://github.com/llvm/llvm-project/pull/81919
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/81919
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/82302
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
The CI failure looks unrelated to this:
```
CMake Error at
C:/BuildTools/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.20/Modules/CMakeDetermineCompilerId.cmake:777
(file):
--
| file STRINGS file
|
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/80687
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/80687
>From 19065e2e25e8bbd735b157239702e4394659bbc7 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Mon, 5 Feb 2024 22:31:19 +0800
Subject: [PATCH 1/2] [docs] [C++20] [Modules] Ideas for transiting to modules
---
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/82302
Close https://github.com/llvm/llvm-project/issues/80570.
In
https://github.com/llvm/llvm-project/commit/a0b6747804e46665ecfd00295b60432bfe1775b6,
we skipped ODR checks for decls in GMF. Then it should be
https://github.com/ChuanqiXu9 approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/82179
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
> Let's zoom out a little. The approach in D41416 shows that it is feasible to
> store _a_ hash of the template arguments to delay eager deserializations. The
> ODR hash approach is a second order problem because we can swap it with
> something better once we need to. In
@@ -0,0 +1,38 @@
+// Test that -print-library-module-manifest-path finds the correct file.
+
+// REQUIRES: x86-registered-target
ChuanqiXu9 wrote:
```suggestion
// FIXME:
// REQUIRES: x86-registered-target
```
I feel better with a FIXME to remind us to
https://github.com/ChuanqiXu9 approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/82160
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/82160
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
> > But my point is that we can't land that if we don't understand what's going
> > wrong without that patch.
>
> We understand that very well and it's described in
> https://reviews.llvm.org/D153003 as well as the surrounding discussions:
> because of the way that
ChuanqiXu9 wrote:
> > > > > > > > > > [do not merge] [runtime-cxxmodules] Rework our lazy
> > > > > > > > > > template specialization deserialization mechanism
> > > > > > > > > > [root-project/root#14495](https://github.com/root-project/root/pull/14495)
> > > > > > > > >
> > > > > > > > >
>
ChuanqiXu9 wrote:
> > > > > > > > [do not merge] [runtime-cxxmodules] Rework our lazy template
> > > > > > > > specialization deserialization mechanism
> > > > > > > > [root-project/root#14495](https://github.com/root-project/root/pull/14495)
> > > > > > >
> > > > > > >
> > > > > > > From
>
ChuanqiXu9 wrote:
> > > > > > > > > [do not merge] [runtime-cxxmodules] Rework our lazy template
> > > > > > > > > specialization deserialization mechanism
> > > > > > > > > [root-project/root#14495](https://github.com/root-project/root/pull/14495)
> > > > > > > >
> > > > > > > >
> > > > > >
ChuanqiXu9 wrote:
> > > > > > > [do not merge] [runtime-cxxmodules] Rework our lazy template
> > > > > > > specialization deserialization mechanism
> > > > > > > [root-project/root#14495](https://github.com/root-project/root/pull/14495)
> > > > > >
> > > > > >
> > > > > > From
> > > > > >
https://github.com/ChuanqiXu9 commented:
Sounds good. My instinct reaction to the title is that you're going to unify
the annoying duplicated interfaces for the 5 specialization classes (function
specialization, class/var (partial) specializations). But it is still good to
merge these
@@ -1792,23 +1807,11 @@ class ClassTemplateSpecializationDecl
llvm::PointerUnion
SpecializedTemplate;
- /// Further info for explicit template specialization/instantiation.
- struct ExplicitSpecializationInfo {
-/// The type-as-written.
-TypeSourceInfo
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/81642
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
> > > > > [do not merge] [runtime-cxxmodules] Rework our lazy template
> > > > > specialization deserialization mechanism
> > > > > [root-project/root#14495](https://github.com/root-project/root/pull/14495)
> > > >
> > > >
> > > > From
> > > >
Author: Chuanqi Xu
Date: 2024-02-18T15:15:28+08:00
New Revision: 1ecbab56dcbb78268c8d19af34a50591f90b12a0
URL:
https://github.com/llvm/llvm-project/commit/1ecbab56dcbb78268c8d19af34a50591f90b12a0
DIFF:
https://github.com/llvm/llvm-project/commit/1ecbab56dcbb78268c8d19af34a50591f90b12a0.diff
ChuanqiXu9 wrote:
> > > [do not merge] [runtime-cxxmodules] Rework our lazy template
> > > specialization deserialization mechanism
> > > [root-project/root#14495](https://github.com/root-project/root/pull/14495)
> >
> >
> > From
> >
ChuanqiXu9 wrote:
> [do not merge] [runtime-cxxmodules] Rework our lazy template specialization
> deserialization mechanism root-project/root#14495
>From https://github.com/root-project/root/pull/14495, I see there is new reply
>saying the testing is actually fine. Do you think we still need
ChuanqiXu9 wrote:
@iains @mizvekov ping~
https://github.com/llvm/llvm-project/pull/75894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
(This is another example that the github review can't work well with the
reverted patches...)
@mordante I think you can add `// REQUIRES: x86-registered-target` to the test
if @kaz7 can't respond quickly. It will skip the test on targets other than
x86. And it should keep
@@ -5097,6 +5099,22 @@ class CoroutineSuspendExpr : public Expr {
return static_cast(SubExprs[SubExpr::Operand]);
}
+ SuspendReturnType getSuspendReturnType() const {
+auto *SuspendExpr = getSuspendExpr();
+assert(SuspendExpr);
+
+auto SuspendType =
@@ -232,16 +250,74 @@ static LValueOrRValue
emitSuspendExpression(CodeGenFunction , CGCoroData
auto *NullPtr = llvm::ConstantPointerNull::get(CGF.CGM.Int8PtrTy);
auto *SaveCall = Builder.CreateCall(CoroSave, {NullPtr});
+ const auto AwaitSuspendCanThrow =
+
@@ -1396,9 +1478,18 @@ static bool simplifySuspendPoint(CoroSuspendInst
*Suspend,
if (!SubFn)
return false;
- // Does not refer to the current coroutine, we cannot do anything with it.
- if (SubFn->getFrame() != CoroBegin)
-return false;
+ auto Frame =
@@ -5038,6 +5038,8 @@ class CoroutineSuspendExpr : public Expr {
OpaqueValueExpr *OpaqueValue = nullptr;
public:
+ enum SuspendReturnType { SuspendVoid, SuspendBool, SuspendHandle };
ChuanqiXu9 wrote:
nit: Add a comment to explain that the return type of
https://github.com/ChuanqiXu9 commented:
Thanks. This looks much better now.
Given the CoroAwaitSuspendInst is lowered before splitting coroutines, I think
we don't need to handle it specially in `CoroSplit` any more.
https://github.com/llvm/llvm-project/pull/79712
@@ -2013,6 +2104,10 @@ splitCoroutine(Function , SmallVectorImpl
,
buildCoroutineFrame(F, Shape, MaterializableCallback);
replaceFrameSizeAndAlignment(Shape);
+ IRBuilder<> Builder(M.getContext());
ChuanqiXu9 wrote:
```suggestion
IRBuilder<>
@@ -380,66 +380,7 @@ static Expr *maybeTailCall(Sema , QualType RetType, Expr
*E,
// __builtin_coro_resume so that the cleanup code are not inserted in-between
// the resume call and return instruction, which would interfere with the
// musttail call contract.
-
@@ -167,6 +167,47 @@ class CoroCloner {
} // end anonymous namespace
+// FIXME:
+// Lower the intrinisc earlier if coroutine frame doesn't escape
ChuanqiXu9 wrote:
```suggestion
// Lower the intrinisc in CoroEarly phase if coroutine frame doesn't escape
```
@@ -232,16 +250,74 @@ static LValueOrRValue
emitSuspendExpression(CodeGenFunction , CGCoroData
auto *NullPtr = llvm::ConstantPointerNull::get(CGF.CGM.Int8PtrTy);
auto *SaveCall = Builder.CreateCall(CoroSave, {NullPtr});
+ const auto AwaitSuspendCanThrow =
+
@@ -338,6 +414,71 @@ static QualType getCoroutineSuspendExprReturnType(const
ASTContext ,
}
#endif
+llvm::Function *
+CodeGenFunction::generateAwaitSuspendWrapper(Twine const ,
+ Twine const ,
+
@@ -232,16 +250,74 @@ static LValueOrRValue
emitSuspendExpression(CodeGenFunction , CGCoroData
auto *NullPtr = llvm::ConstantPointerNull::get(CGF.CGM.Int8PtrTy);
auto *SaveCall = Builder.CreateCall(CoroSave, {NullPtr});
+ const auto AwaitSuspendCanThrow =
+
@@ -173,19 +173,36 @@ static bool ResumeStmtCanThrow(const Stmt *S) {
return false;
}
+static bool AwaitSuspendStmtCanThrow(const Stmt *S) {
+ return ResumeStmtCanThrow(S);
+}
+
// Emit suspend expression which roughly looks like:
//
// auto && x = CommonExpr();
//
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/79712
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
I'd like to land this in 2 weeks if no more comments come in.
https://github.com/llvm/llvm-project/pull/80687
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 requested changes to this pull request.
This is not wanted. While we have a policy to revert patches if the patches
break existing codes, the C++20 modules support in clangd is literally broken:
https://github.com/clangd/clangd/issues/1293
Also the ability to
ChuanqiXu9 wrote:
@sam-mccall ping~. Let's see if we can make it in clang19.
https://github.com/llvm/llvm-project/pull/66462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
yes if I remember correctly. I am away from the computer so I can't find the
wording.
But I don't think this is related to how the frame gets allocated.
https://github.com/llvm/llvm-project/pull/81195
___
cfe-commits mailing list
ChuanqiXu9 wrote:
I feel whether the param is needed is not related whether the allocation
happens.
The param isn't needed means it is not used.
https://github.com/llvm/llvm-project/pull/81195
___
cfe-commits mailing list
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/80687
>From 2fcbdb034613ea6fdea4ce9efd5656116edb2ca1 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Mon, 5 Feb 2024 22:31:19 +0800
Subject: [PATCH] [docs] [C++20] [Modules] Ideas for transiting to modules
---
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/80687
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/80687
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/80687
>From 7a9fb425a7dfb6429af969ec741c23c1e577e5fa Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Mon, 5 Feb 2024 22:31:19 +0800
Subject: [PATCH] [docs] [C++20] [Modules] Ideas for transiting to modules
---
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/80687
This patch tries to provide some ideas to transform an existing libraries to
modules. I feel this is helpful for users who is interested in modules from my
observation. While the syntax of modules look easy
@@ -0,0 +1,42 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+//
+// RUN: %clang_cc1 -std=c++20 -I %t %t/A.cppm -emit-module-interface -o
%t/A.pcm -verify
+// RUN: %clang_cc1 -std=c++20 -I %t %t/B.cpp -fmodule-file=A=%t/A.pcm
-fsyntax-only -verify -ast-dump-all
@@ -0,0 +1,42 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+//
+// RUN: %clang_cc1 -std=c++20 -I %t %t/A.cppm -emit-module-interface -o
%t/A.pcm -verify
+// RUN: %clang_cc1 -std=c++20 -I %t %t/B.cpp -fmodule-file=A=%t/A.pcm
-fsyntax-only -verify -ast-dump-all
ChuanqiXu9 wrote:
> This patch does too many things for me to be able to review it. This patch
> fails on our infrastructure.
>
> I'd propose to simplify it to basically D41416 + the on-disk hash table. We
> should read all of the entries upon module loading to simplify the logic in
>
ChuanqiXu9 wrote:
> There is a lot of activity going on just in `clang/test/AST`, with multiple
> commits a day. I think there is a time and place, and the right tradeoffs for
> all kinds of tests we have. Shall we get others opinions? Shall we make an
> RFC so we get the community aligned on
@@ -0,0 +1,42 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+//
+// RUN: %clang_cc1 -std=c++20 -I %t %t/A.cppm -emit-module-interface -o
%t/A.pcm -verify
+// RUN: %clang_cc1 -std=c++20 -I %t %t/B.cpp -fmodule-file=A=%t/A.pcm
-fsyntax-only -verify -ast-dump-all
@@ -0,0 +1,40 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+//
+// RUN: %clang_cc1 -std=c++20 -I %t %t/A.cppm -emit-module-interface -o
%t/A.pcm -verify
+// RUN: %clang_cc1 -std=c++20 -I %t %t/B.cppm -emit-module-interface -o
%t/B.pcm -verify
+// RUN:
@@ -0,0 +1,40 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+//
+// RUN: %clang_cc1 -std=c++20 -I %t %t/A.cppm -emit-module-interface -o
%t/A.pcm -verify
+// RUN: %clang_cc1 -std=c++20 -I %t %t/B.cppm -emit-module-interface -o
%t/B.pcm -verify
+// RUN:
https://github.com/ChuanqiXu9 commented:
I still think the testing for dumped text is not acceptable. Let's make it
prettier in unittest.
https://github.com/llvm/llvm-project/pull/80245
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
ChuanqiXu9 wrote:
> I took a look at what sort of complexity unittest would entail here. I don't
> think it's a good compromise complexity wise, it's a lot of boilerplate just
> to test a few AST nodes are correctly linked.
But they are much easier to maintain than dumpped AST text. I feel
ChuanqiXu9 wrote:
But the test for dumpped text still looks not good. Can we get rid of that?
https://github.com/llvm/llvm-project/pull/80245
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
ChuanqiXu9 wrote:
> The issue is up: #80252
Thanks. Although I feel it is too implementor's view, (I mean the end users can
hardly understand it), it is much better.
> Yeah, looking at the similarities, there is a decent chance this is the same
> issue, it's worth trying it out.
Yeah, let's
@@ -0,0 +1,42 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+//
+// RUN: %clang_cc1 -std=c++20 -I %t %t/A.cppm -emit-module-interface -o
%t/A.pcm -verify
+// RUN: %clang_cc1 -std=c++20 -I %t %t/B.cpp -fmodule-file=A=%t/A.pcm
-fsyntax-only -verify -ast-dump-all
601 - 700 of 1547 matches
Mail list logo
