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

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

[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 &M) : Lowere

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

[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 &M) : Lowere

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

[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

[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 %t/

[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] [llvm] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

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

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

@@ -338,6 +386,85 @@ static QualType getCoroutineSuspendExprReturnType(const ASTContext &Ctx, } #endif +llvm::Function *CodeGenFunction::generateAwaitSuspendHelper( +Twine const &CoroName, Twine const &SuspendPointName, +CoroutineSuspendExpr const &S, bool CanThrow) {

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

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

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

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

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

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

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

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

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

@@ -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 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][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)

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

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)

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 https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-co

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

[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 https://l

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

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

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

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] [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 > reading

[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] [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] [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 --- cla

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

[clang] [Modules] [HeaderSearch] Don't reenter headers if it is pragma once (PR #76119)

https://github.com/ChuanqiXu9 updated https://github.com/llvm/llvm-project/pull/76119 >From 65fdddbd501b36f7dcef2db3fd25a7a4a1f80a0b Mon Sep 17 00:00:00 2001 From: Chuanqi Xu Date: Thu, 21 Dec 2023 11:24:14 +0800 Subject: [PATCH] [Modules] [HeaderSearch] Don't reenter headers if it is pragma o

[clang] [Modules] [HeaderSearch] Don't reenter headers if it is pragma once (PR #76119)

@@ -1458,7 +1458,7 @@ bool HeaderSearch::ShouldEnterIncludeFile(Preprocessor &PP, } else { // Otherwise, if this is a #include of a file that was previously #import'd // or if this is the second #include of a #pragma once file, ignore it. -if ((FileInfo.isPragmaO

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

https://github.com/ChuanqiXu9 created https://github.com/llvm/llvm-project/pull/79261 This comes from when I playing around clang-repl with moduels : ) I succeeded to import std with https://libcxx.llvm.org/Modules.html and calling `std::printf` after this patch. I want to put the documentati

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

https://github.com/ChuanqiXu9 closed 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)

ChuanqiXu9 wrote: > Hi @ChuanqiXu9, the test you added is failing on the PS4 bot because for the > PS4 target, it requires an external linker which is not present/available. > Can the test be rewritten to not require linking? > > https://lab.llvm.org/buildbot/#/builders/139/builds/57928 > > `

[clang] c125965 - [NFC] Add more requirement to clang/test/Interpreter/cxx20-modules.cppm

Author: Chuanqi Xu Date: 2024-01-24T16:10:49+08:00 New Revision: c1259650e742e7b3053f6520729b4c1f44c27814 URL: https://github.com/llvm/llvm-project/commit/c1259650e742e7b3053f6520729b4c1f44c27814 DIFF: https://github.com/llvm/llvm-project/commit/c1259650e742e7b3053f6520729b4c1f44c27814.diff LO

[clang] bae1ada - [docs] [C++20] [Modules] Document how to import modules in clang-repl

Author: Chuanqi Xu Date: 2024-01-24T16:14:14+08:00 New Revision: bae1adae1c7cdf3b0bd618fc9cd5af251dc901ed URL: https://github.com/llvm/llvm-project/commit/bae1adae1c7cdf3b0bd618fc9cd5af251dc901ed DIFF: https://github.com/llvm/llvm-project/commit/bae1adae1c7cdf3b0bd618fc9cd5af251dc901ed.diff LO

[clang] Revert "[Modules] [HeaderSearch] Don't reenter headers if it is pragm… (PR #79396)

https://github.com/ChuanqiXu9 approved this pull request. LGTM. Sorry for forgetting testing lldb : ( https://github.com/llvm/llvm-project/pull/79396 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinf

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

ChuanqiXu9 wrote: > For what it's worth, this test appears to fail when > `LLVM_DEFAULT_TARGET_TRIPLE` is changed (my script sets it to the output of > my Linux distribution's `clang -print-target-triple`) > > ``` > error: PCH file was compiled for the target 'x86_64-pc-linux-gnu' but the > c

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

ChuanqiXu9 wrote: It looks true but the test does the same thing as other tests to build modules 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

[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 630e59738990c3dd570065b8b7a050d822d68df0 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 modul

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

@@ -0,0 +1,50 @@ +// REQUIRES: !system-windows + +// RUN: rm -rf %t +// RUN: split-file %s %t +// RUN: cd %t +// +// RUN: %clang_cc1 -std=c++20 %t/layer1.cppm -triple %itanium_abi_triple \ +// RUN: -emit-module-interface -o %t/foo-layer1.pcm +// RUN: %clang_cc1 -std=c++20 %t/l

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

@@ -1801,6 +1801,12 @@ void ItaniumCXXABI::emitVTableDefinitions(CodeGenVTables &CGVT, if (VTable->hasInitializer()) return; + // If the class are attached to a C++ named module other than the one ChuanqiXu9 wrote: Done https://github.com/llvm/llvm-p

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

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

[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] [clang-scan-deps] Fix check for empty `Compilation` (PR #75545)

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

[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] 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 LO

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

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

[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 > (comment)

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

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

[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] 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 decl

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

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

[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] [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 tha

[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 https:

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

[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 ___ cfe-com

[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 https://lists.llvm.org/c

[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] [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 decl

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

[clang] [clang][modules] Print library module manifest path. (PR #76451)

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

[clang] [clang][modules] Print library module manifest path. (PR #76451)

@@ -0,0 +1,9 @@ +// Test that -print-library-module-manifest-path finds the correct file. +// +// Note this file is currently not available on Apple platforms ChuanqiXu9 wrote: I don't get the intention for the test since there is standard library related things

[clang] [clang][modules] Print library module manifest path. (PR #76451)

https://github.com/ChuanqiXu9 commented: LGTM generally. https://github.com/llvm/llvm-project/pull/76451 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][modules] Print library module manifest path. (PR #76451)

@@ -6135,6 +6141,42 @@ std::string Driver::GetProgramPath(StringRef Name, const ToolChain &TC) const { return std::string(Name); } +std::string Driver::GetStdModuleManifestPath(const Compilation &C, + const ToolChain &TC) const {

[clang] [clang][modules] Print library module manifest path. (PR #76451)

@@ -0,0 +1,15 @@ +// Test that -print-library-module-manifest-path finds the correct file. + +// RUN: %clang -print-library-module-manifest-path \ +// RUN: -stdlib=libc++ \ +// RUN: --sysroot=%S/Inputs/cxx23_modules \ +// RUN: --target=x86_64-linux-gnu 2>&1 \ +// RUN:

[clang] [clang][modules] Print library module manifest path. (PR #76451)

@@ -6135,6 +6141,42 @@ std::string Driver::GetProgramPath(StringRef Name, const ToolChain &TC) const { return std::string(Name); } +std::string Driver::GetStdModuleManifestPath(const Compilation &C, + const ToolChain &TC) const {

[clang] [coroutines][coro_lifetimebound] Detect lifetime issues with lambda captures (PR #77066)

@@ -297,6 +297,26 @@ struct ReadySuspendResumeResult { bool IsInvalid; }; +// Adds [[clang::coro_wrapper]] and [[clang::coro_disable_lifetimebound]] +// attributes to `get_return_object`. +static void handleGetReturnObject(Sema &S, MemberExpr *ME) { + if (!ME || !ME->getMem

[clang] dc4e85b - [C++20] [Modules] Remove hardcoded path to imported module in BMIs

Author: Chuanqi Xu Date: 2024-01-12T13:47:59+08:00 New Revision: dc4e85bd79ff17014cbbe4a9db1d9b91929e91ce URL: https://github.com/llvm/llvm-project/commit/dc4e85bd79ff17014cbbe4a9db1d9b91929e91ce DIFF: https://github.com/llvm/llvm-project/commit/dc4e85bd79ff17014cbbe4a9db1d9b91929e91ce.diff LO

[clang] 4b99af3 - [docs] Update doc for C++20 Modules after dc4e85b

Author: Chuanqi Xu Date: 2024-01-12T14:16:19+08:00 New Revision: 4b99af34199208e82f6a8806bfae1d3dea007936 URL: https://github.com/llvm/llvm-project/commit/4b99af34199208e82f6a8806bfae1d3dea007936 DIFF: https://github.com/llvm/llvm-project/commit/4b99af34199208e82f6a8806bfae1d3dea007936.diff LO

[clang] Fix crash with modules and constexpr destructor (PR #69076)

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

[clang] [clang][modules] Print library module manifest path. (PR #76451)

https://github.com/ChuanqiXu9 approved this pull request. LGTM. While we need to delete `clang/test/Driver/Inputs/cxx23_modules/usr/lib/x86_64-linux-gnu/libc++.so` and `clang/test/Driver/Inputs/cxx23_modules/usr/lib/x86_64-linux-gnu/modules.json`. https://github.com/llvm/llvm-project/pull/764

[clang] [coroutines][coro_lifetimebound] Detect lifetime issues with lambda captures (PR #77066)

@@ -1796,6 +1797,32 @@ bool CoroutineStmtBuilder::makeOnException() { return true; } +// Adds [[clang::coro_wrapper]] and [[clang::coro_disable_lifetimebound]] +// attributes to the function `get_return_object`. +static void handleGetReturnObject(Sema &S, Expr *E) { + if (a

[clang] [coroutines][coro_lifetimebound] Detect lifetime issues with lambda captures (PR #77066)

@@ -15845,8 +15845,10 @@ void Sema::CheckCoroutineWrapper(FunctionDecl *FD) { RecordDecl *RD = FD->getReturnType()->getAsRecordDecl(); if (!RD || !RD->getUnderlyingDecl()->hasAttr()) return; - // Allow `get_return_object()`. - if (FD->getDeclName().isIdentifier() && +

[clang] [coroutines][coro_lifetimebound] Detect lifetime issues with lambda captures (PR #77066)

@@ -1796,6 +1797,32 @@ bool CoroutineStmtBuilder::makeOnException() { return true; } +// Adds [[clang::coro_wrapper]] and [[clang::coro_disable_lifetimebound]] +// attributes to the function `get_return_object`. ChuanqiXu9 wrote: ```suggestion // attributes

[clang] [coroutines][coro_lifetimebound] Detect lifetime issues with lambda captures (PR #77066)

@@ -33,6 +34,7 @@ #include "llvm/ADT/SmallString.h" #include "llvm/ADT/SmallVector.h" #include "llvm/ADT/StringExtras.h" +#include "llvm/Support/Casting.h" ChuanqiXu9 wrote: Maybe we don't need this? https://github.com/llvm/llvm-project/pull/77066 ___

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