[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)

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

[clang] [clangd] Fix C++20 modules crash (PR #81919)

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

[clang-tools-extra] [clangd] [C++20] [Modules] Introduce initial support for C++20 Modules (PR #66462)

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

[clang] [Clang] CGCoroutine: Skip moving parameters if the allocation decision is false (PR #81195)

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

[clang] [Clang] CGCoroutine: Skip moving parameters if the allocation decision is false (PR #81195)

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

[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)

@@ -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

[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)

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 ---

[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)

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

[clang] [docs] [C++20] [Modules] Ideas for transitioning to modules (PR #80687)

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

[clang] [docs] [C++20] [Modules] Ideas for transforming to modules (PR #80687)

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 ---

[clang] [docs] [C++20] [Modules] Ideas for transforming to modules (PR #80687)

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

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

@@ -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

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

@@ -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

[clang] [Serialization] Load Specializations Lazily (PR #76774)

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 >

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

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

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

@@ -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

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

@@ -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:

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

@@ -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:

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

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

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

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

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

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

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

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

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

@@ -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

[clang] [Clang][test] Limit library search when linking shared lib (PR #80253)

https://github.com/ChuanqiXu9 approved this pull request. LGTM. Thanks. https://github.com/llvm/llvm-project/pull/80253 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

https://github.com/ChuanqiXu9 edited https://github.com/llvm/llvm-project/pull/80245 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

@@ -181,6 +181,9 @@ Bug Fixes to C++ Support and (`#79745 `_) - Fix incorrect code generation caused by the object argument of ``static operator()`` and ``static operator[]`` calls not being evaluated. Fixes (`#67976

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

@@ -181,6 +181,9 @@ Bug Fixes to C++ Support and (`#79745 `_) - Fix incorrect code generation caused by the object argument of ``static operator()`` and ``static operator[]`` calls not being evaluated. Fixes (`#67976

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

@@ -181,6 +181,9 @@ Bug Fixes to C++ Support and (`#79745 `_) - Fix incorrect code generation caused by the object argument of ``static operator()`` and ``static operator[]`` calls not being evaluated. Fixes (`#67976

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

@@ -181,6 +181,9 @@ Bug Fixes to C++ Support and (`#79745 `_) - Fix incorrect code generation caused by the object argument of ``static operator()`` and ``static operator[]`` calls not being evaluated. Fixes (`#67976

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

https://github.com/ChuanqiXu9 commented: IIRC, in https://github.com/llvm/llvm-project/pull/79959, you're saying the patch have the potential to fix https://github.com/llvm/llvm-project/issues/78850? Is it true? https://github.com/llvm/llvm-project/pull/80245

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

@@ -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

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

https://github.com/ChuanqiXu9 edited https://github.com/llvm/llvm-project/pull/80245 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

@@ -181,6 +181,9 @@ Bug Fixes to C++ Support and (`#79745 `_) - Fix incorrect code generation caused by the object argument of ``static operator()`` and ``static operator[]`` calls not being evaluated. Fixes (`#67976

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

ChuanqiXu9 wrote: Before looking into it, I remember the user branch is only allowed for stacked review. If this patch is not the case, let's try to create a new PR. https://github.com/llvm/llvm-project/pull/80245 ___ cfe-commits mailing list

[clang] [clang] fix merging of UsingShadowDecl (PR #80245)

https://github.com/ChuanqiXu9 edited https://github.com/llvm/llvm-project/pull/80245 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20] [Modules] Introduce reduced BMI (PR #75894)

ChuanqiXu9 wrote: @mizvekov would you like to take a look at this? This is related (in some level) to what you say https://github.com/llvm/llvm-project/pull/79959. In short, in the direction, in the one-phase compilation, the pcm won't be compiled into object files. (But it still will in the

[clang] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf (PR #79959)

https://github.com/ChuanqiXu9 closed https://github.com/llvm/llvm-project/pull/79959 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf (PR #79959)

@@ -457,6 +457,28 @@ Note that **currently** the compiler doesn't consider inconsistent macro definit Currently Clang would accept the above example. But it may produce surprising results if the debugging code depends on consistent use of ``NDEBUG`` also in other translation

[clang] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf (PR #79959)

https://github.com/ChuanqiXu9 edited https://github.com/llvm/llvm-project/pull/79959 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf (PR #79959)

@@ -457,6 +457,28 @@ Note that **currently** the compiler doesn't consider inconsistent macro definit Currently Clang would accept the above example. But it may produce surprising results if the debugging code depends on consistent use of ``NDEBUG`` also in other translation

[clang] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf (PR #79959)

@@ -457,6 +457,28 @@ Note that **currently** the compiler doesn't consider inconsistent macro definit Currently Clang would accept the above example. But it may produce surprising results if the debugging code depends on consistent use of ``NDEBUG`` also in other translation

[clang] [C++20] [Modules] Introduce reduced BMI (PR #75894)

ChuanqiXu9 wrote: @iains would you like to take a look on this. I feel OK to not land this in 18 but I think it is really important to land this in 19. Although it is still early to that, there are other works to do (e.g., the next patch and more testing). So it may be better to start it

[clang] d71831a - [NFC] [clang-repl] Fix test failures due to incosistent target settings

Author: Chuanqi Xu Date: 2024-01-31T16:05:15+08:00 New Revision: d71831a2172e4cf7c3f3540c472ce2aeb14d4505 URL: https://github.com/llvm/llvm-project/commit/d71831a2172e4cf7c3f3540c472ce2aeb14d4505 DIFF: https://github.com/llvm/llvm-project/commit/d71831a2172e4cf7c3f3540c472ce2aeb14d4505.diff

[llvm] [clang] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

ChuanqiXu9 wrote: BTW, in my original comment, I said: > Then in the middle end, we can perform analysis the awaitSuspendFn to see if > the coroutine handle escapes or not. If it won't escape, we can replace above > intrinsic to the direct call. Otherwise, we will only convert them in the >

[llvm] [clang] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

@@ -338,6 +386,85 @@ static QualType getCoroutineSuspendExprReturnType(const ASTContext , } #endif +llvm::Function *CodeGenFunction::generateAwaitSuspendHelper( +Twine const , Twine const , +CoroutineSuspendExpr const , bool CanThrow) { + std::string FuncName =

[clang] [llvm] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

@@ -232,16 +237,59 @@ static LValueOrRValue emitSuspendExpression(CodeGenFunction , CGCoroData auto *NullPtr = llvm::ConstantPointerNull::get(CGF.CGM.Int8PtrTy); auto *SaveCall = Builder.CreateCall(CoroSave, {NullPtr}); - CGF.CurCoro.InSuspendBlock = true; - auto

[llvm] [clang] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

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

[clang] Support C++20 Modules in clang-repl (PR #79261)

@@ -0,0 +1,31 @@ +// UNSUPPORTED: system-aix +// +// RUN: rm -rf %t +// RUN: mkdir -p %t +// RUN: split-file %s %t +// +// RUN: %clang -std=c++20 %t/mod.cppm --precompile \ +// RUN: -o %t/mod.pcm +// RUN: %clang %t/mod.pcm -c -o %t/mod.o +// RUN: %clang -shared %t/mod.o -o

[clang] [Serialization] Load Specializations Lazily (PR #76774)

ChuanqiXu9 wrote: I applied the change to https://github.com/ChuanqiXu9/root/tree/LoadSpecLazily And the testing result looks like, hmm, unstable, there are 326 tests failed out of 2174 and in the LoadSpecLazily version, there are 328 tests out of 2174. But some tests passed in LoadSpecLazily

[llvm] [clang] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

@@ -1553,6 +1625,9 @@ static bool hasCallsInBlocksBetween(BasicBlock *SaveBB, BasicBlock *ResDesBB) { } static bool hasCallsBetween(Instruction *Save, Instruction *ResumeOrDestroy) { + if (Save == ResumeOrDestroy) +return false; ChuanqiXu9 wrote: How

[llvm] [clang] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

@@ -79,6 +79,73 @@ using namespace llvm; namespace { +// Created on demand if the coro-early pass has work to do. +class Lowerer : public coro::LowererBase { + IRBuilder<> Builder; + void lowerAwaitSuspend(CoroAwaitSuspendInst *CB); + +public: + Lowerer(Module ) :

[clang] [llvm] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

@@ -79,6 +79,73 @@ using namespace llvm; namespace { +// Created on demand if the coro-early pass has work to do. +class Lowerer : public coro::LowererBase { ChuanqiXu9 wrote: Why do we need to inherit `coro::LowererBase`? Can't we make it directly in a

[clang] [llvm] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

@@ -338,6 +386,85 @@ static QualType getCoroutineSuspendExprReturnType(const ASTContext , } #endif +llvm::Function *CodeGenFunction::generateAwaitSuspendHelper( ChuanqiXu9 wrote: For such function definitions, generally we need a comment about its reasoning

[clang] [llvm] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

@@ -79,6 +79,73 @@ using namespace llvm; namespace { +// Created on demand if the coro-early pass has work to do. +class Lowerer : public coro::LowererBase { + IRBuilder<> Builder; + void lowerAwaitSuspend(CoroAwaitSuspendInst *CB); + +public: + Lowerer(Module ) :

[clang] [llvm] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

@@ -232,16 +237,59 @@ static LValueOrRValue emitSuspendExpression(CodeGenFunction , CGCoroData auto *NullPtr = llvm::ConstantPointerNull::get(CGF.CGM.Int8PtrTy); auto *SaveCall = Builder.CreateCall(CoroSave, {NullPtr}); - CGF.CurCoro.InSuspendBlock = true; - auto

[clang] [llvm] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

@@ -1744,6 +1744,273 @@ a call to ``llvm.coro.suspend.retcon`` after resuming abnormally. In a yield-once coroutine, it is undefined behavior if the coroutine executes a call to ``llvm.coro.suspend.retcon`` after resuming in any way. +.. _coro.await.suspend: +

[llvm] [clang] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

@@ -1744,6 +1744,273 @@ a call to ``llvm.coro.suspend.retcon`` after resuming abnormally. In a yield-once coroutine, it is undefined behavior if the coroutine executes a call to ``llvm.coro.suspend.retcon`` after resuming in any way. +.. _coro.await.suspend: +

[clang] [llvm] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

@@ -232,16 +237,59 @@ static LValueOrRValue emitSuspendExpression(CodeGenFunction , CGCoroData auto *NullPtr = llvm::ConstantPointerNull::get(CGF.CGM.Int8PtrTy); auto *SaveCall = Builder.CreateCall(CoroSave, {NullPtr}); - CGF.CurCoro.InSuspendBlock = true; - auto

[clang] [llvm] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

@@ -1744,6 +1744,273 @@ a call to ``llvm.coro.suspend.retcon`` after resuming abnormally. In a yield-once coroutine, it is undefined behavior if the coroutine executes a call to ``llvm.coro.suspend.retcon`` after resuming in any way. +.. _coro.await.suspend: +

[clang] [llvm] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

@@ -79,6 +79,73 @@ using namespace llvm; namespace { +// Created on demand if the coro-early pass has work to do. +class Lowerer : public coro::LowererBase { + IRBuilder<> Builder; + void lowerAwaitSuspend(CoroAwaitSuspendInst *CB); + +public: + Lowerer(Module ) :

[llvm] [clang] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

@@ -5036,14 +5036,17 @@ class CoroutineSuspendExpr : public Expr { Stmt *SubExprs[SubExpr::Count]; OpaqueValueExpr *OpaqueValue = nullptr; + OpaqueValueExpr *OpaqueFramePtr = nullptr; ChuanqiXu9 wrote: I still think we can get rid of storing

[llvm] [clang] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

@@ -232,16 +237,59 @@ static LValueOrRValue emitSuspendExpression(CodeGenFunction , CGCoroData auto *NullPtr = llvm::ConstantPointerNull::get(CGF.CGM.Int8PtrTy); auto *SaveCall = Builder.CreateCall(CoroSave, {NullPtr}); - CGF.CurCoro.InSuspendBlock = true; - auto

[clang] [llvm] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

@@ -173,6 +173,10 @@ static bool ResumeStmtCanThrow(const Stmt *S) { return false; } +static bool AwaitSuspendStmtCanThrow(const Stmt *S) { + return ResumeStmtCanThrow(S); +} ChuanqiXu9 wrote: Maybe it will be better to rename `ResumeStmtCanThrow` to

[clang] [llvm] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

https://github.com/ChuanqiXu9 commented: I got the reason why I felt `__await_suspend_helper_` was odd. In my imagination, we only need to emit the function `await_suspend(handle)` to an LLVM function and pass that to `llvm.coro.await.suspend` directly.

[llvm] [clang] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

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

[clang] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf (PR #79959)

ChuanqiXu9 wrote: > I'd still idly vote against adding this flag/support - but if other modules > contributors feel it's the right thing to do, I won't stand in the way. Yeah, as @mizvekov said, this is intended to be a transparent change to users. (unless the users are testing volunteers,

[clang] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf (PR #79959)

@@ -457,6 +457,28 @@ Note that **currently** the compiler doesn't consider inconsistent macro definit Currently Clang would accept the above example. But it may produce surprising results if the debugging code depends on consistent use of ``NDEBUG`` also in other translation

[clang] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf (PR #79959)

@@ -457,6 +457,28 @@ Note that **currently** the compiler doesn't consider inconsistent macro definit Currently Clang would accept the above example. But it may produce surprising results if the debugging code depends on consistent use of ``NDEBUG`` also in other translation

[clang] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf (PR #79959)

https://github.com/ChuanqiXu9 updated https://github.com/llvm/llvm-project/pull/79959 >From beb1a4b89f941f41a6e220447dcda6d6fc231a0b Mon Sep 17 00:00:00 2001 From: Chuanqi Xu Date: Tue, 30 Jan 2024 15:57:35 +0800 Subject: [PATCH 1/2] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf Close

[clang] Support C++20 Modules in clang-repl (PR #79261)

@@ -0,0 +1,31 @@ +// UNSUPPORTED: system-aix +// +// RUN: rm -rf %t +// RUN: mkdir -p %t +// RUN: split-file %s %t +// +// RUN: %clang -std=c++20 %t/mod.cppm --precompile \ +// RUN: -o %t/mod.pcm +// RUN: %clang %t/mod.pcm -c -o %t/mod.o +// RUN: %clang -shared %t/mod.o -o

[clang] Support C++20 Modules in clang-repl (PR #79261)

@@ -0,0 +1,31 @@ +// UNSUPPORTED: system-aix +// +// RUN: rm -rf %t +// RUN: mkdir -p %t +// RUN: split-file %s %t +// +// RUN: %clang -std=c++20 %t/mod.cppm --precompile \ +// RUN: -o %t/mod.pcm +// RUN: %clang %t/mod.pcm -c -o %t/mod.o +// RUN: %clang -shared %t/mod.o -o

[clang] Support C++20 Modules in clang-repl (PR #79261)

https://github.com/ChuanqiXu9 commented: This is what I had in mind https://github.com/llvm/llvm-project/pull/79261 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Support C++20 Modules in clang-repl (PR #79261)

https://github.com/ChuanqiXu9 edited https://github.com/llvm/llvm-project/pull/79261 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-scan-deps] Fix check for empty `Compilation` (PR #75545)

https://github.com/ChuanqiXu9 closed https://github.com/llvm/llvm-project/pull/75545 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-scan-deps] Fix check for empty `Compilation` (PR #75545)

https://github.com/ChuanqiXu9 approved this pull request. LGTM then. https://github.com/llvm/llvm-project/pull/75545 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Serialization] Check for stack exhaustion when reading declarations (PR #79875)

ChuanqiXu9 wrote: > with stack exhaustion warning, the compiler can continue (albeit being slow > or unstable). The depth limit here will be a hard restriction and so there > will be no workaround if the code reaches it. It is a surprise to me that this is only a warning instead of a hard

[clang] [Serialization] Check for stack exhaustion when reading declarations (PR #79875)

ChuanqiXu9 wrote: > I am not saying it's a bad idea to add this for testing purposes, but given > how fragile this approach is, I think we should not provide configuration > knobs to users there. At least everyone sees crashes at roughly the same > points right now (although variation is

[clang] [Serialization] Check for stack exhaustion when reading declarations (PR #79875)

@@ -4099,7 +4099,9 @@ Decl *ASTReader::ReadDeclRecord(DeclID ID) { // calls to Decl::getASTContext() by Decl's methods will find the // TranslationUnitDecl without crashing. D->setDeclContext(Context.getTranslationUnitDecl()); - Reader.Visit(D); + + // Reading some

[clang] Support C++20 Modules in clang-repl (PR #79261)

ChuanqiXu9 wrote: > > > IncrementalExtensions > > > > > > But the change itself is to make `IncrementalExtensions` a compatible lang > > options. So that we don't need to specify it when generating the modules. > > I mean conditionally if `IncrementalExtensions` is set we change the target

[clang] Support C++20 Modules in clang-repl (PR #79261)

ChuanqiXu9 wrote: I am wondering if it helps if we specify the target triple in the test, then it won't be so troublesome. https://github.com/llvm/llvm-project/pull/79261 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] Support C++20 Modules in clang-repl (PR #79261)

ChuanqiXu9 wrote: > IncrementalExtensions But the change itself is to make `IncrementalExtensions` a compatible lang options. So that we don't need to specify it when generating the modules. https://github.com/llvm/llvm-project/pull/79261 ___

[clang] [Serialization] Load Specializations Lazily (PR #76774)

ChuanqiXu9 wrote: > > > > > As far as I can tell from [#76774 > > > > > (comment)](https://github.com/llvm/llvm-project/pull/76774#issuecomment-1914177330) > > > > > above, the last push only changed the default value of > > > > > `LoadExternalSpecializationsLazily`. In that case, my test

[clang] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf (PR #79959)

https://github.com/ChuanqiXu9 updated https://github.com/llvm/llvm-project/pull/79959 >From beb1a4b89f941f41a6e220447dcda6d6fc231a0b Mon Sep 17 00:00:00 2001 From: Chuanqi Xu Date: Tue, 30 Jan 2024 15:57:35 +0800 Subject: [PATCH] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf Close

[clang] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf (PR #79959)

https://github.com/ChuanqiXu9 created https://github.com/llvm/llvm-project/pull/79959 Close https://github.com/llvm/llvm-project/issues/79240 Cite the comment from @mizvekov in //github.com/llvm/llvm-project/issues/79240: > There are two kinds of bugs / issues relevant here: > > Clang bugs

[clang] [Serialization] Check for stack exhaustion when reading declarations (PR #79875)

ChuanqiXu9 wrote: Another idea is to limit (or check) the threshold for `ASTReader::NumCurrentElementsDeserializing`. Then we still can print the stack trace by some utils in LLVM also we can get better performance than this. https://github.com/llvm/llvm-project/pull/79875

[clang] [Serialization] Check for stack exhaustion when reading declarations (PR #79875)

@@ -0,0 +1,43 @@ +// RUN: rm -rf %t +// RUN: mkdir -p %t +// RUN: split-file %s %t + +// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/usings.cppm -o %t/usings.pcm +// RUN: %clang_cc1 -std=c++20 -fmodule-file=usings=%t/usings.pcm %t/use.cpp -verify -fsyntax-only

[clang] [Serialization] Check for stack exhaustion when reading declarations (PR #79875)

https://github.com/ChuanqiXu9 commented: To make this testable, maybe we can refactor `clang::runWithSufficientStackSpace` a little bit to make `DesiredStackSize` and `isStackNearlyExhausted::SufficientStack` configurable. https://github.com/llvm/llvm-project/pull/79875

[clang] [Serialization] Check for stack exhaustion when reading declarations (PR #79875)

@@ -4099,7 +4099,9 @@ Decl *ASTReader::ReadDeclRecord(DeclID ID) { // calls to Decl::getASTContext() by Decl's methods will find the // TranslationUnitDecl without crashing. D->setDeclContext(Context.getTranslationUnitDecl()); - Reader.Visit(D); + + // Reading some

[clang] [Serialization] Check for stack exhaustion when reading declarations (PR #79875)

https://github.com/ChuanqiXu9 edited https://github.com/llvm/llvm-project/pull/79875 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Serialization] Load Specializations Lazily (PR #76774)

ChuanqiXu9 wrote: > > > As far as I can tell from [#76774 > > > (comment)](https://github.com/llvm/llvm-project/pull/76774#issuecomment-1914177330) > > > above, the last push only changed the default value of > > > `LoadExternalSpecializationsLazily`. In that case, my test results from > > >

[llvm] [clang] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

https://github.com/ChuanqiXu9 commented: Thanks for looking into this. I haven't looked it in details. Given this is complex, it should take a relative longer time. Here is some quick feedbacks: - Every time we change the non-static data members of AST nodes, we need to update the

[clang] [Serialization] Load Specializations Lazily (PR #76774)

ChuanqiXu9 wrote: > As far as I can tell from [#76774 > (comment)](https://github.com/llvm/llvm-project/pull/76774#issuecomment-1914177330) > above, the last push only changed the default value of > `LoadExternalSpecializationsLazily`. In that case, my test results from > [#76774 >

[clang] [Serialization] Load Specializations Lazily (PR #76774)

ChuanqiXu9 wrote: > The newest version of this patch still doesn't work correctly. Switching the > new `LoadExternalSpecializationsLazily` to disabled by default (somehow the > argument didn't work on its own) instead crashes, most of the cases involving > `MultiOnDiskHashTable`. I suspect

[clang] 4118082 - [C++20] [Modules] Remove previous workaround for odr hashing enums

Author: Chuanqi Xu Date: 2024-01-29T14:35:23+08:00 New Revision: 4118082f651a05cca258c684ab1199578b57afac URL: https://github.com/llvm/llvm-project/commit/4118082f651a05cca258c684ab1199578b57afac DIFF: https://github.com/llvm/llvm-project/commit/4118082f651a05cca258c684ab1199578b57afac.diff

[clang] a0b6747 - [C++20] [Modules] Don't perform ODR checks in GMF

Author: Chuanqi Xu Date: 2024-01-29T11:44:59+08:00 New Revision: a0b6747804e46665ecfd00295b60432bfe1775b6 URL: https://github.com/llvm/llvm-project/commit/a0b6747804e46665ecfd00295b60432bfe1775b6 DIFF: https://github.com/llvm/llvm-project/commit/a0b6747804e46665ecfd00295b60432bfe1775b6.diff

[clang] [clang-scan-deps] Fix check for empty `Compilation` (PR #75545)

https://github.com/ChuanqiXu9 edited https://github.com/llvm/llvm-project/pull/75545 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-scan-deps] Fix check for empty `Compilation` (PR #75545)

@@ -728,7 +728,7 @@ getCompilationDataBase(int argc, char **argv, std::string ) { *Diags); std::unique_ptr C( TheDriver.BuildCompilation(CommandLine)); - if (!C) + if (C->getJobs().empty()) ChuanqiXu9 wrote: ```suggestion

[clang] [clang-scan-deps] Fix check for empty `Compilation` (PR #75545)

https://github.com/ChuanqiXu9 commented: It will be better to have a test for this. https://github.com/llvm/llvm-project/pull/75545 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)

https://github.com/ChuanqiXu9 updated https://github.com/llvm/llvm-project/pull/75912 >From 7a5c4ccd37b263a4d3d01df16591b576a64e839f Mon Sep 17 00:00:00 2001 From: Chuanqi Xu Date: Tue, 19 Dec 2023 17:00:59 +0800 Subject: [PATCH] [C++20] [Modules] [Itanium ABI] Generate the vtable in the

[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)

@@ -1046,6 +1046,15 @@ CodeGenModule::getVTableLinkage(const CXXRecordDecl *RD) { if (!RD->isExternallyVisible()) return llvm::GlobalVariable::InternalLinkage; + // Previously we'll decide the linkage of the vtable by the linkage + // of the key function. But within

<    1   2   3   4   5   6   7   8   9   10   >