[clang] [Clang][Sema] Expose static inline functions from GMF (PR #104701)

Jan =?utf-8?q?Kokemüller?= Message-ID: In-Reply-To: @@ -6926,11 +6926,26 @@ void Sema::AddOverloadCandidate( /// have linkage. So that all entities of the same should share one /// linkage. But in clang, different entities of the same could have /// different lin

[clang] [Clang][Sema] Expose static inline functions from GMF (PR #104701)

Jan =?utf-8?q?Kokemüller?= Message-ID: In-Reply-To: @@ -6926,11 +6926,26 @@ void Sema::AddOverloadCandidate( /// have linkage. So that all entities of the same should share one /// linkage. But in clang, different entities of the same could have /// different lin

[clang] [Clang][Sema] Expose static inline functions from GMF (PR #104701)

Jan =?utf-8?q?Kokemüller?= Message-ID: In-Reply-To: @@ -6926,11 +6926,26 @@ void Sema::AddOverloadCandidate( /// have linkage. So that all entities of the same should share one /// linkage. But in clang, different entities of the same could have /// different lin

[clang] [RFC][C++20][Modules] Fix crash when function and lambda inside loaded from different modules (PR #104512)

ChuanqiXu9 wrote: Here is another example that merging lambdas are problematic: https://github.com/llvm/llvm-project/issues/102721. Although I think we need to solve the problems separately. They are different problems. > > I feel the change is somewhat odd to me. Since the description is abo

[clang] 522c253 - [Coroutines] Salvage the debug information for coroutine frames within optimizations

Author: Chuanqi Xu Date: 2024-08-20T17:21:43+08:00 New Revision: 522c253f47ea27d8eeb759e06f8749092b1de71e URL: https://github.com/llvm/llvm-project/commit/522c253f47ea27d8eeb759e06f8749092b1de71e DIFF: https://github.com/llvm/llvm-project/commit/522c253f47ea27d8eeb759e06f8749092b1de71e.diff LO

[clang] [Clang][Sema] Expose static inline functions from GMF (PR #104701)

Jan =?utf-8?q?Kokemüller?= , Jan =?utf-8?q?Kokemüller?= , Jan =?utf-8?q?Kokemüller?= Message-ID: In-Reply-To: @@ -6926,11 +6926,26 @@ void Sema::AddOverloadCandidate( /// have linkage. So that all entities of the same should share one /// linkage. But in clang, differ

[clang] [clang][NFC] remove resolved issue from StandardCPlusPlusModules.rst (PR #105610)

https://github.com/ChuanqiXu9 approved this pull request. Oh, I forgot it. Thanks~ https://github.com/llvm/llvm-project/pull/105610 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][NFC] remove resolved issue from StandardCPlusPlusModules.rst (PR #105610)

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

[clang] [Clang][Sema] Expose static inline functions from GMF (PR #104701)

Jan =?utf-8?q?Kokemüller?= , Jan =?utf-8?q?Kokemüller?= , Jan =?utf-8?q?Kokemüller?= Message-ID: In-Reply-To: @@ -6926,11 +6926,26 @@ void Sema::AddOverloadCandidate( /// have linkage. So that all entities of the same should share one /// linkage. But in clang, differ

[clang] [RFC][C++20][Modules] Fix crash when function and lambda inside loaded from different modules (PR #104512)

ChuanqiXu9 wrote: Yeah, while the implementation need to be polished, the shape is what I want. https://github.com/llvm/llvm-project/pull/104512 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe

[clang] e5f196e - [NFCI] [C++20] [Modules] Relax the case for duplicated declaration in multiple module units for explicit specialization

Author: Chuanqi Xu Date: 2024-08-23T15:35:57+08:00 New Revision: e5f196e4e7e3aec5c19adeacb7191ed0a099ea9a URL: https://github.com/llvm/llvm-project/commit/e5f196e4e7e3aec5c19adeacb7191ed0a099ea9a DIFF: https://github.com/llvm/llvm-project/commit/e5f196e4e7e3aec5c19adeacb7191ed0a099ea9a.diff LO

[clang] 39986f0 - [NFCI] [Serialization] Use demoteThisDefinitionToDeclaration instead of setCompleteDefinition(false) for CXXRecordDecl

Author: Chuanqi Xu Date: 2024-08-23T15:43:43+08:00 New Revision: 39986f0b4d797e4ad3c12607f2b4abe2322b82bb URL: https://github.com/llvm/llvm-project/commit/39986f0b4d797e4ad3c12607f2b4abe2322b82bb DIFF: https://github.com/llvm/llvm-project/commit/39986f0b4d797e4ad3c12607f2b4abe2322b82bb.diff LO

[clang] [C++20] [Modules] Warn for duplicated decls in mutliple module units (PR #105799)

https://github.com/ChuanqiXu9 created https://github.com/llvm/llvm-project/pull/105799 It is a long standing issue that the duplicated declarations in multiple module units would cause the compilation performance to get slowed down. And there are many questions or issue reports. So I think it

[clang] [C++20] [Modules] Warn for duplicated decls in mutliple module units (PR #105799)

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

[clang] [clang][test] Rewrote test to work with lit internal shell syntax (PR #105902)

https://github.com/ChuanqiXu9 approved this pull request. LGTM on my side. Thanks. But I didn't take a detailed look into https://discourse.llvm.org/t/rfc-enabling-the-lit-internal-shell-by-default/80179/29. So it might be good to wait for people there to approve this https://github.com/llvm/

[clang] [C++20] [Modules] Warn for duplicated decls in mutliple module units (PR #105799)

@@ -9955,6 +9955,45 @@ void ASTReader::finishPendingActions() { } PendingDefinitions.clear(); + for (auto [D, Previous] : PendingWarningForDuplicatedDefsInModuleUnits) { +auto hasDefinitionImpl = [this](Decl *D, auto hasDefinitionImpl) { + if (auto *VD = dyn_cast

[clang] 88f9ac3 - [doc] [C++20] [Modules] Add docs and release notes for '-Wdecls-in-multiple-modules'

Author: Chuanqi Xu Date: 2024-08-26T10:52:05+08:00 New Revision: 88f9ac380d8b40742aea11c8278652711261abff URL: https://github.com/llvm/llvm-project/commit/88f9ac380d8b40742aea11c8278652711261abff DIFF: https://github.com/llvm/llvm-project/commit/88f9ac380d8b40742aea11c8278652711261abff.diff LO

[clang] 1ecc5ae - [Serialization] Register Speical types before register decls

Author: Chuanqi Xu Date: 2024-06-24T11:08:46+08:00 New Revision: 1ecc5ae13b9061cfb37ef0c409c8a4fc4bad42c9 URL: https://github.com/llvm/llvm-project/commit/1ecc5ae13b9061cfb37ef0c409c8a4fc4bad42c9 DIFF: https://github.com/llvm/llvm-project/commit/1ecc5ae13b9061cfb37ef0c409c8a4fc4bad42c9.diff LO

[clang] 4061354 - [Serialization] Revert specialization for DenseMapInfo::getHashValue

Author: Chuanqi Xu Date: 2024-06-24T11:20:09+08:00 New Revision: 4061354ab3157255238cf2664b9482bd6297dc83 URL: https://github.com/llvm/llvm-project/commit/4061354ab3157255238cf2664b9482bd6297dc83 DIFF: https://github.com/llvm/llvm-project/commit/4061354ab3157255238cf2664b9482bd6297dc83.diff LO

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

https://github.com/ChuanqiXu9 created https://github.com/llvm/llvm-project/pull/96453 (Some backgrounds, not required to read: https://discourse.llvm.org/t/rfc-c-20-modules-introduce-thin-bmi-and-decls-hash/74755) This is the document part for the no-transitive-change (https://github.com/llvm

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

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

[clang] 79b0966 - [NFC] [Serialization] Refactor getLocalDeclID to 'LocalDeclID::get'

Author: Chuanqi Xu Date: 2024-06-24T14:10:52+08:00 New Revision: 79b0966f2f137869cabab42d094fc1ccbb58373c URL: https://github.com/llvm/llvm-project/commit/79b0966f2f137869cabab42d094fc1ccbb58373c DIFF: https://github.com/llvm/llvm-project/commit/79b0966f2f137869cabab42d094fc1ccbb58373c.diff LO

[clang] [Serialization] Storing DeclID separately (PR #95897)

https://github.com/ChuanqiXu9 updated https://github.com/llvm/llvm-project/pull/95897 >From 0e6b0ee59605d28bb031d8c2fb70fb853d853605 Mon Sep 17 00:00:00 2001 From: Chuanqi Xu Date: Tue, 18 Jun 2024 11:28:03 +0800 Subject: [PATCH] [Serialization] Store DeclID in two slots to utilize VBR6 format

[clang] [Serialization] Storing DeclID separately (PR #95897)

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

[clang] [Serialization] Storing DeclID separately (PR #95897)

ChuanqiXu9 wrote: @ilya-biryukov I think this is ready to review and test. I think this can mitigate the size increase with the DeclID change. https://github.com/llvm/llvm-project/pull/95897 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http

[clang] 790f931 - [NFC] [Modules] Extract the logic to decide whether the module units belongs to the same module

Author: Chuanqi Xu Date: 2024-06-24T15:58:46+08:00 New Revision: 790f931886a03324714f31a626eef7e9c609ae97 URL: https://github.com/llvm/llvm-project/commit/790f931886a03324714f31a626eef7e9c609ae97 DIFF: https://github.com/llvm/llvm-project/commit/790f931886a03324714f31a626eef7e9c609ae97.diff LO

[clang] 2232881 - [C++20] [Modules] Avoid comparing primary module name to decide isInSameModule all the time

Author: Chuanqi Xu Date: 2024-06-24T16:55:17+08:00 New Revision: 2232881736f1a7e3e94ee1123dea1b6cd85a9c3a URL: https://github.com/llvm/llvm-project/commit/2232881736f1a7e3e94ee1123dea1b6cd85a9c3a DIFF: https://github.com/llvm/llvm-project/commit/2232881736f1a7e3e94ee1123dea1b6cd85a9c3a.diff LO

[clang] cc4ec6d - [C++20] [Modules] Diagnose redeclarations from different modules

Author: Chuanqi Xu Date: 2024-06-24T19:03:31+08:00 New Revision: cc4ec6daf0d4f43110e8220d542c1155b8c1ef51 URL: https://github.com/llvm/llvm-project/commit/cc4ec6daf0d4f43110e8220d542c1155b8c1ef51 DIFF: https://github.com/llvm/llvm-project/commit/cc4ec6daf0d4f43110e8220d542c1155b8c1ef51.diff LO

[clang] [Serialization] Don't read all declaration id eagerly when merge the tables (PR #95506)

ChuanqiXu9 wrote: > I feel the increased complexity does not seem like a good trade-off if it > does not significantly improve performance. However I don't feel too strongly > about it, so I suggest you get a second opinion if you feel strongly that we > should land this. Yeah, and I don't ha

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

ChuanqiXu9 wrote: > I really like the idea of documenting this, hopefully this create some > fruitful discussions with the build system developers and other compiler > users. > > After trying to put myself into the shoes of the compiler users reading this, > I can't help but think that the "n

[clang] fa20184 - [C++20] [Modules] [Serialization] Don't reuse type ID and identifier ID from imported modules

Author: Chuanqi Xu Date: 2024-06-25T15:04:32+08:00 New Revision: fa20184a8f336e4154f2ffeeeb8a538dc9462d9a URL: https://github.com/llvm/llvm-project/commit/fa20184a8f336e4154f2ffeeeb8a538dc9462d9a DIFF: https://github.com/llvm/llvm-project/commit/fa20184a8f336e4154f2ffeeeb8a538dc9462d9a.diff LO

[clang] [Serialization] Storing DeclID separately (PR #95897)

ChuanqiXu9 wrote: > Thanks for this patch, I will try it on our codebase to see the effects of it > and report back to you. I am also trying to understand in which cases this > would be a win and when not. IIUC, this is always a win when `ModuleFileIndex > != 0` and a pessimization otherwise.

[clang] [Clang] Access tls_guard via llvm.threadlocal.address (PR #96633)

@@ -1059,9 +1059,10 @@ CodeGenFunction::GenerateCXXGlobalInitFunc(llvm::Function *Fn, if (Guard.isValid()) { // If we have a guard variable, check whether we've already performed // these initializations. This happens for TLS initialization functions. - ll

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

https://github.com/ChuanqiXu9 updated https://github.com/llvm/llvm-project/pull/96453 >From a035ae25314f3168f73108988f2bb7671e7d9e7f Mon Sep 17 00:00:00 2001 From: Chuanqi Xu Date: Mon, 24 Jun 2024 11:41:23 +0800 Subject: [PATCH 1/2] [Doc] Update documentation for no-transitive-change --- cla

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -229,6 +229,10 @@ C++20 Feature Support will now work. (#GH62925). +- Clang refactored the BMI format to make it possible to support no transitive changes ChuanqiXu9 wrote: Good suggestions. Applied. (Just change `should` to `can`. Since I feel `shou

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] 2ee2b6a - [Coroutines] Clear FirstVLALoc in time

Author: Chuanqi Xu Date: 2024-06-26T13:25:06+08:00 New Revision: 2ee2b6aa7a3d9ba6ba13f6881b25e26d7d12c823 URL: https://github.com/llvm/llvm-project/commit/2ee2b6aa7a3d9ba6ba13f6881b25e26d7d12c823 DIFF: https://github.com/llvm/llvm-project/commit/2ee2b6aa7a3d9ba6ba13f6881b25e26d7d12c823.diff LO

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

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

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Clang] Access tls_guard via llvm.threadlocal.address (PR #96633)

@@ -1059,9 +1059,15 @@ CodeGenFunction::GenerateCXXGlobalInitFunc(llvm::Function *Fn, if (Guard.isValid()) { // If we have a guard variable, check whether we've already performed // these initializations. This happens for TLS initialization functions. - ll

[clang] [Clang] Access tls_guard via llvm.threadlocal.address (PR #96633)

@@ -1070,13 +1076,26 @@ CodeGenFunction::GenerateCXXGlobalInitFunc(llvm::Function *Fn, // Mark as initialized before initializing anything else. If the // initializers use previously-initialized thread_local vars, that's // probably supposed to be OK, but the

[clang] [Clang] Access tls_guard via llvm.threadlocal.address (PR #96633)

@@ -1059,9 +1059,15 @@ CodeGenFunction::GenerateCXXGlobalInitFunc(llvm::Function *Fn, if (Guard.isValid()) { // If we have a guard variable, check whether we've already performed // these initializations. This happens for TLS initialization functions. - ll

[clang] [Clang] Access tls_guard via llvm.threadlocal.address (PR #96633)

@@ -1070,13 +1076,26 @@ CodeGenFunction::GenerateCXXGlobalInitFunc(llvm::Function *Fn, // Mark as initialized before initializing anything else. If the // initializers use previously-initialized thread_local vars, that's // probably supposed to be OK, but the

[clang] [Clang] Access tls_guard via llvm.threadlocal.address (PR #96633)

@@ -1059,9 +1059,15 @@ CodeGenFunction::GenerateCXXGlobalInitFunc(llvm::Function *Fn, if (Guard.isValid()) { // If we have a guard variable, check whether we've already performed // these initializations. This happens for TLS initialization functions. - ll

[clang] [HLSL] Implement `export` keyword (PR #96823)

ChuanqiXu9 wrote: The grammer looks exactly the same with modules. May it be compatible with modules? https://github.com/llvm/llvm-project/pull/96823 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listin

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

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

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

https://github.com/ChuanqiXu9 updated https://github.com/llvm/llvm-project/pull/96453 >From a035ae25314f3168f73108988f2bb7671e7d9e7f Mon Sep 17 00:00:00 2001 From: Chuanqi Xu Date: Mon, 24 Jun 2024 11:41:23 +0800 Subject: [PATCH 1/3] [Doc] Update documentation for no-transitive-change --- cla

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Doc] Update documentation for no-transitive-change (PR #96453)

@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Tra

[clang] [Clang] Access tls_guard via llvm.threadlocal.address (PR #96633)

@@ -1059,9 +1059,15 @@ CodeGenFunction::GenerateCXXGlobalInitFunc(llvm::Function *Fn, if (Guard.isValid()) { // If we have a guard variable, check whether we've already performed // these initializations. This happens for TLS initialization functions. - ll

[clang] [Clang] Access tls_guard via llvm.threadlocal.address (PR #96633)

@@ -1070,13 +1076,26 @@ CodeGenFunction::GenerateCXXGlobalInitFunc(llvm::Function *Fn, // Mark as initialized before initializing anything else. If the // initializers use previously-initialized thread_local vars, that's // probably supposed to be OK, but the

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

ChuanqiXu9 wrote: @kadircet ping~ 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] 76864e6 - [C++20] [Modules] Don't find module for linkage for decls in global

Author: Chuanqi Xu Date: 2024-06-28T16:12:50+08:00 New Revision: 76864e6af134aa240069d42ba15e0b89fd7d6b4c URL: https://github.com/llvm/llvm-project/commit/76864e6af134aa240069d42ba15e0b89fd7d6b4c DIFF: https://github.com/llvm/llvm-project/commit/76864e6af134aa240069d42ba15e0b89fd7d6b4c.diff LO

[clang] [RFC][C++20][Modules] Fix crash when function and lambda inside loaded from different modules (PR #104512)

Valentin Clement =?utf-8?b?KOODkOODrOODsw=?=,Kyungwoo Lee ,Dmitry Polukhin ,Dmitry Polukhin Message-ID: In-Reply-To: @@ -1155,6 +1155,16 @@ void ASTDeclReader::VisitFunctionDecl(FunctionDecl *FD) { for (unsigned I = 0; I != NumParams; ++I) Params.push_back(readDeclAs

[clang] [clang-scan-deps] Infer the target from the executable name (PR #108189)

https://github.com/ChuanqiXu9 commented: LGTM but I'll leave this to @jansvoboda11 and @Bigcheese https://github.com/llvm/llvm-project/pull/108189 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/

[clang] [RFC][C++20][Modules] Fix crash when function and lambda inside loaded from different modules (PR #104512)

Valentin Clement =?utf-8?b?KOODkOODrOODsw=?=,Kyungwoo Lee ,Dmitry Polukhin ,Dmitry Polukhin Message-ID: In-Reply-To: @@ -1155,6 +1155,16 @@ void ASTDeclReader::VisitFunctionDecl(FunctionDecl *FD) { for (unsigned I = 0; I != NumParams; ++I) Params.push_back(readDeclAs

[clang] [C++20] [Modules] Warn for importing implementation partition unit in interface units (PR #108493)

https://github.com/ChuanqiXu9 created https://github.com/llvm/llvm-project/pull/108493 Recently, there are multiple false positive issue reports about the reachability of implementation partition units: - https://github.com/llvm/llvm-project/issues/105882 - https://github.com/llvm/llvm-project/

[clang] [C++20] [Modules] Warn for importing implementation partition unit in interface units (PR #108493)

https://github.com/ChuanqiXu9 updated https://github.com/llvm/llvm-project/pull/108493 >From b109ea29ee6d1c290766e141ce75317fbf450767 Mon Sep 17 00:00:00 2001 From: Chuanqi Xu Date: Fri, 13 Sep 2024 13:18:43 +0800 Subject: [PATCH] [C++20] [Modules] Warn for importing implementation partition u

[clang] [C++20] [Modules] Warn for importing implementation partition unit in interface units (PR #108493)

https://github.com/ChuanqiXu9 updated https://github.com/llvm/llvm-project/pull/108493 >From b109ea29ee6d1c290766e141ce75317fbf450767 Mon Sep 17 00:00:00 2001 From: Chuanqi Xu Date: Fri, 13 Sep 2024 13:18:43 +0800 Subject: [PATCH 1/2] [C++20] [Modules] Warn for importing implementation partiti

[clang] [C++20] [Modules] Warn for importing implementation partition unit in interface units (PR #108493)

@@ -439,6 +439,9 @@ def warn_deprecated_literal_operator_id: Warning< "is deprecated">, InGroup, DefaultIgnore; def warn_reserved_module_name : Warning< "%0 is a reserved name for a module">, InGroup; +def warn_import_implementation_partition_unit_in_interface_unit : Warnin

[clang] [Clang] Propagate elide safe context through [[clang::coro_must_await]] (PR #108474)

@@ -849,12 +849,30 @@ static bool isAttributedCoroAwaitElidable(const QualType &QT) { return Record && Record->hasAttr(); } -static bool isCoroAwaitElidableCall(Expr *Operand) { - if (!Operand->isPRValue()) { -return false; +static void applySafeElideContext(Expr *Oper

[clang] [Clang] Propagate elide safe context through [[clang::coro_must_await]] (PR #108474)

@@ -249,7 +249,10 @@ Attribute Changes in Clang (#GH106864) - Introduced a new attribute ``[[clang::coro_await_elidable]]`` on coroutine return types - to express elideability at call sites where the coroutine is co_awaited as a prvalue. + to express elideability at call

[clang] [C++20] [Modules] Warn for importing implementation partition unit in interface units (PR #108493)

https://github.com/ChuanqiXu9 updated https://github.com/llvm/llvm-project/pull/108493 >From 75c361b60d177093c43795ebae5f41dbc35ae769 Mon Sep 17 00:00:00 2001 From: Chuanqi Xu Date: Fri, 13 Sep 2024 13:18:43 +0800 Subject: [PATCH] [C++20] [Modules] Warn for importing implementation partition u

[clang] [C++20] [Modules] Warn for importing implementation partition unit in interface units (PR #108493)

@@ -439,6 +439,10 @@ def warn_deprecated_literal_operator_id: Warning< "is deprecated">, InGroup, DefaultIgnore; def warn_reserved_module_name : Warning< "%0 is a reserved name for a module">, InGroup; +def warn_import_implementation_partition_unit_in_interface_unit : Warni

[clang] [C++20] [Modules] Warn for importing implementation partition unit in interface units (PR #108493)

ChuanqiXu9 wrote: > This should probably come with a release note so that users know about the > improved diagnostic behavior. Done https://github.com/llvm/llvm-project/pull/108493 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists

[clang] [C++20] [Modules] Warn for importing implementation partition unit in interface units (PR #108493)

@@ -650,6 +650,14 @@ DeclResult Sema::ActOnModuleImport(SourceLocation StartLoc, else VisibleModules.setVisible(Mod, ImportLoc); + assert((!Mod->isModulePartitionImplementation() || getCurrentModule()) && + "We can only import a partition unit in a named module.

[clang] [Clang] Propagate elide safe context through [[clang::coro_must_await]] (PR #108474)

@@ -249,7 +249,10 @@ Attribute Changes in Clang (#GH106864) - Introduced a new attribute ``[[clang::coro_await_elidable]]`` on coroutine return types - to express elideability at call sites where the coroutine is co_awaited as a prvalue. + to express elideability at call

[clang] [C++20] [Modules] Warn for importing implementation partition unit in interface units (PR #108493)

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

[clang] [RFC][C++20][Modules] Relax ODR check in unnamed modules (PR #111160)

@@ -2527,7 +2527,7 @@ class BitsUnpacker { inline bool shouldSkipCheckingODR(const Decl *D) { return D->getASTContext().getLangOpts().SkipODRCheckInGMF && - D->isFromGlobalModule(); + (D->isFromGlobalModule() || !D->isInNamedModule()); Chuanq

[clang] [RFC][C++20][Modules] Relax ODR check in unnamed modules (PR #111160)

@@ -2527,7 +2527,7 @@ class BitsUnpacker { inline bool shouldSkipCheckingODR(const Decl *D) { return D->getASTContext().getLangOpts().SkipODRCheckInGMF && - D->isFromGlobalModule(); + (D->isFromGlobalModule() || !D->isInNamedModule()); Chuanq

[clang-tools-extra] [clangd] [Modules] Support Reusable Modules Builder (PR #106683)

ChuanqiXu9 wrote: @kadircet ping~ It will be pretty good for the users if we can have this for clang20. https://github.com/llvm/llvm-project/pull/106683 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/lis

[clang] [ASTWriter] Detect more non-affecting FileIDs to reduce source location duplication (PR #112015)

@@ -192,13 +201,13 @@ GetAffectingModuleMaps(const Preprocessor &PP, Module *RootModule) { // The containing module map is affecting, because it's being pointed // into by Module::DefinitionLoc. - if (auto FE = MM.getContainingModuleMapFile(Mod)) -Mod

[clang] [C++20][Modules] Load function body from the module that gives canonical decl (PR #111992)

@@ -10057,15 +10057,18 @@ void ASTReader::finishPendingActions() { // For a function defined inline within a class template, force the // canonical definition to be the one inside the canonical definition of // the template. This ensures that we instantiate fr

[clang] [clang] LazyOffsetPtr: Use native pointer width (PR #111995)

@@ -326,25 +326,25 @@ struct LazyOffsetPtr { /// /// If the low bit is clear, a pointer to the AST node. If the low /// bit is set, the upper 63 bits are the offset. - mutable uint64_t Ptr = 0; + mutable uintptr_t Ptr = 0; public: LazyOffsetPtr() = default; - exp

[clang] [C++20][Modules] Load function body from the module that gives canonical decl (PR #111992)

@@ -10057,15 +10057,18 @@ void ASTReader::finishPendingActions() { // For a function defined inline within a class template, force the // canonical definition to be the one inside the canonical definition of // the template. This ensures that we instantiate fr

[clang] [ASTWriter] Detect more non-affecting FileIDs to reduce source location duplication (PR #112015)

https://github.com/ChuanqiXu9 approved this pull request. looks good to me. Please leave some time to @jansvoboda11 https://github.com/llvm/llvm-project/pull/112015 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin

[clang] [ASTWriter] Detect more non-affecting FileIDs to reduce source location duplication (PR #112015)

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

[clang] [ASTWriter] Detect more non-affecting FileIDs to reduce source location duplication (PR #112015)

@@ -192,13 +201,13 @@ GetAffectingModuleMaps(const Preprocessor &PP, Module *RootModule) { // The containing module map is affecting, because it's being pointed // into by Module::DefinitionLoc. - if (auto FE = MM.getContainingModuleMapFile(Mod)) -Mod

[clang] [clang] LazyOffsetPtr: Use native pointer width (PR #111995)

ChuanqiXu9 wrote: > Can we remove `getAddressOfPointer` instead?. Where is it being used? It is used in `VarDecl::getInitAddress()` in Decl.cpp. It looks like it is used indirectly by the StmtIterator https://github.com/llvm/llvm-project/pull/111995

[clang] [Clang] Instantiate the correct lambda call operator (PR #110446)

@@ -644,8 +646,8 @@ New features if class of allocation and deallocation function mismatches. `Documentation `__. -- Function effects, e.g. the ``nonblocking`` and ``nonallocating`` "perfo

[clang] [RFC][C++20][Modules] Relax ODR check in unnamed modules (PR #111160)

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

[clang] [C++20][Modules] Allow import for a header unit after #pragma (PR #111662)

@@ -951,9 +951,16 @@ void Preprocessor::Lex(Token &Result) { break; [[fallthrough]]; default: - TrackGMFState.handleMisc(); - StdCXXImportSeqState.handleMisc(); - ModuleDeclState.handleMisc(); + if (tok::isPragmaAnnotation(Result.getKind())

[clang-tools-extra] [clangd] [C++20] [Modules] Support code complete for C++20 modules (PR #110083)

https://github.com/ChuanqiXu9 updated https://github.com/llvm/llvm-project/pull/110083 >From e35e600159c99736de7d2bc735c738002f592988 Mon Sep 17 00:00:00 2001 From: Chuanqi Xu Date: Thu, 26 Sep 2024 13:43:51 +0800 Subject: [PATCH 1/5] [clangd] [C++20] [Modules] Support code complete for C++20

<    13   14   15   16   17   18   19   20   21   22   >