[clang] [Modules] No transitive source location change (PR #86912)

2024-03-28 Thread Chuanqi Xu via cfe-commits

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


[clang] [Modules] No transitive source location change (PR #86912)

2024-03-28 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

 BTW, after this patch, with reduced BMI 
(https://github.com/llvm/llvm-project/pull/85050), we can already do something 
more interesting than reformating:

```
//--- A.cppm
export module A;
int funcA0();
int funcA1();
export int funcA() {
return funcA0();
}

//--- A.v1.cppm
export module A;

int funcA0();
int funcA1();
export int funcA() {
return funcA0() + funcA1();
}

//--- B.cppm
export module B;
import A;

export int funcB() {
return funcA();
}
```

Now the B.pcm will keep unchanged  with `A.pcm` from `A.cppm` and `A.v1.pcm` 
from `A.v1.cppm`. We changed the implementation of `funcA()` from `return 
funcA0();` to `return funcA0() + funcA1();`. And the `B.pcm` can still get the 
same content.

https://github.com/llvm/llvm-project/pull/86912
___
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)

2024-03-28 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

@rjmccall @dwblaikie ping

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


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

2024-03-28 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

@sam-mccall any updates?

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] [Modules] No transitive source location change (PR #86912)

2024-03-28 Thread Chuanqi Xu via cfe-commits

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


[clang] [Modules] No transitive source location change (PR #86912)

2024-03-28 Thread Chuanqi Xu via cfe-commits

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


[clang] [Modules] No transitive source location change (PR #86912)

2024-03-28 Thread Chuanqi Xu via cfe-commits

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


[clang] [Modules] No transitive source location change (PR #86912)

2024-03-28 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 updated 
https://github.com/llvm/llvm-project/pull/86912

>From 8d4e349710f4ca84a7ad2dd8aa71afa50b730dbb Mon Sep 17 00:00:00 2001
From: Chuanqi Xu 
Date: Mon, 18 Mar 2024 08:36:55 +0800
Subject: [PATCH] [Modules] No transitive source location change

---
 clang/include/clang/Basic/SourceLocation.h|  1 +
 .../include/clang/Serialization/ASTBitCodes.h | 56 ++--
 clang/include/clang/Serialization/ASTReader.h | 54 +++-
 clang/include/clang/Serialization/ASTWriter.h |  4 +
 .../include/clang/Serialization/ModuleFile.h  |  4 -
 .../Serialization/SourceLocationEncoding.h| 78 +++--
 clang/lib/Frontend/ASTUnit.cpp|  2 -
 clang/lib/Serialization/ASTReader.cpp | 86 +++
 clang/lib/Serialization/ASTReaderDecl.cpp |  2 +-
 clang/lib/Serialization/ASTWriter.cpp | 41 +++--
 clang/lib/Serialization/ASTWriterDecl.cpp |  8 +-
 clang/lib/Serialization/ModuleFile.cpp|  1 -
 .../no-transitive-source-location-change.cppm | 69 +++
 clang/test/Modules/pr61067.cppm   | 25 --
 .../SourceLocationEncodingTest.cpp| 66 ++
 15 files changed, 264 insertions(+), 233 deletions(-)
 create mode 100644 clang/test/Modules/no-transitive-source-location-change.cppm

diff --git a/clang/include/clang/Basic/SourceLocation.h 
b/clang/include/clang/Basic/SourceLocation.h
index 00b1e0fa855b7a..7a0f5ba8d1270b 100644
--- a/clang/include/clang/Basic/SourceLocation.h
+++ b/clang/include/clang/Basic/SourceLocation.h
@@ -90,6 +90,7 @@ class SourceLocation {
   friend class ASTWriter;
   friend class SourceManager;
   friend struct llvm::FoldingSetTrait;
+  friend class SourceLocationEncoding;
 
 public:
   using UIntTy = uint32_t;
diff --git a/clang/include/clang/Serialization/ASTBitCodes.h 
b/clang/include/clang/Serialization/ASTBitCodes.h
index f31efa5117f0d1..628ce03572fea6 100644
--- a/clang/include/clang/Serialization/ASTBitCodes.h
+++ b/clang/include/clang/Serialization/ASTBitCodes.h
@@ -22,6 +22,7 @@
 #include "clang/Basic/IdentifierTable.h"
 #include "clang/Basic/OperatorKinds.h"
 #include "clang/Basic/SourceLocation.h"
+#include "clang/Serialization/SourceLocationEncoding.h"
 #include "llvm/ADT/DenseMapInfo.h"
 #include "llvm/Bitstream/BitCodes.h"
 #include 
@@ -175,45 +176,38 @@ const unsigned int NUM_PREDEF_SUBMODULE_IDS = 1;
 
 /// Source range/offset of a preprocessed entity.
 struct PPEntityOffset {
+  using RawLocEncoding = SourceLocationEncoding::RawLocEncoding;
+
   /// Raw source location of beginning of range.
-  SourceLocation::UIntTy Begin;
+  RawLocEncoding Begin;
 
   /// Raw source location of end of range.
-  SourceLocation::UIntTy End;
+  RawLocEncoding End;
 
   /// Offset in the AST file relative to ModuleFile::MacroOffsetsBase.
   uint32_t BitOffset;
 
-  PPEntityOffset(SourceRange R, uint32_t BitOffset)
-  : Begin(R.getBegin().getRawEncoding()), End(R.getEnd().getRawEncoding()),
-BitOffset(BitOffset) {}
-
-  SourceLocation getBegin() const {
-return SourceLocation::getFromRawEncoding(Begin);
-  }
+  PPEntityOffset(RawLocEncoding Begin, RawLocEncoding End, uint32_t BitOffset)
+  : Begin(Begin), End(End), BitOffset(BitOffset) {}
 
-  SourceLocation getEnd() const {
-return SourceLocation::getFromRawEncoding(End);
-  }
+  RawLocEncoding getBegin() const { return Begin; }
+  RawLocEncoding getEnd() const { return End; }
 };
 
 /// Source range of a skipped preprocessor region
 struct PPSkippedRange {
+  using RawLocEncoding = SourceLocationEncoding::RawLocEncoding;
+
   /// Raw source location of beginning of range.
-  SourceLocation::UIntTy Begin;
+  RawLocEncoding Begin;
   /// Raw source location of end of range.
-  SourceLocation::UIntTy End;
+  RawLocEncoding End;
 
-  PPSkippedRange(SourceRange R)
-  : Begin(R.getBegin().getRawEncoding()), End(R.getEnd().getRawEncoding()) 
{
-  }
+  PPSkippedRange(RawLocEncoding Begin, RawLocEncoding End)
+  : Begin(Begin), End(End) {}
 
-  SourceLocation getBegin() const {
-return SourceLocation::getFromRawEncoding(Begin);
-  }
-  SourceLocation getEnd() const {
-return SourceLocation::getFromRawEncoding(End);
-  }
+  RawLocEncoding getBegin() const { return Begin; }
+  RawLocEncoding getEnd() const { return End; }
 };
 
 /// Offset in the AST file. Use splitted 64-bit integer into low/high
@@ -239,8 +233,10 @@ struct UnderalignedInt64 {
 
 /// Source location and bit offset of a declaration.
 struct DeclOffset {
+  using RawLocEncoding = SourceLocationEncoding::RawLocEncoding;
+
   /// Raw source location.
-  SourceLocation::UIntTy Loc = 0;
+  RawLocEncoding RawLoc = 0;
 
   /// Offset relative to the start of the DECLTYPES_BLOCK block. Keep
   /// structure alignment 32-bit and avoid padding gap because undefined
@@ -248,17 +244,15 @@ struct DeclOffset {
   UnderalignedInt64 BitOffset;
 
   DeclOffset() = default;
-  DeclOffset(SourceLocation Loc, uint64_t BitOffset,

[clang] [llvm] [Modules] No transitive source location change (PR #86912)

2024-03-27 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 created 
https://github.com/llvm/llvm-project/pull/86912

None

>From 9046d2156cb8641cccf76c643b6f88994105f452 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu 
Date: Mon, 18 Mar 2024 08:36:55 +0800
Subject: [PATCH] [Modules] No transitive source location change

---
 clang/include/clang/Basic/SourceLocation.h|   1 +
 .../include/clang/Serialization/ASTBitCodes.h |  55 +-
 clang/include/clang/Serialization/ASTReader.h |  48 +
 clang/include/clang/Serialization/ASTWriter.h |   3 +
 .../include/clang/Serialization/ModuleFile.h  |   4 -
 .../Serialization/SourceLocationEncoding.h|  40 +--
 clang/lib/Frontend/ASTUnit.cpp|   2 -
 clang/lib/Serialization/ASTReader.cpp |  87 ++-
 clang/lib/Serialization/ASTReaderDecl.cpp |   2 +-
 clang/lib/Serialization/ASTWriter.cpp |  35 --
 clang/lib/Serialization/ASTWriterDecl.cpp |   6 +-
 clang/lib/Serialization/ModuleFile.cpp|   1 -
 .../no-transitive-source-location-change.cppm |  69 
 clang/test/Modules/pr61067.cppm   |  25 -
 .../SourceLocationEncodingTest.cpp| 100 --
 llvm/lib/Bitcode/Reader/BitcodeAnalyzer.cpp   |   7 +-
 16 files changed, 238 insertions(+), 247 deletions(-)
 create mode 100644 clang/test/Modules/no-transitive-source-location-change.cppm

diff --git a/clang/include/clang/Basic/SourceLocation.h 
b/clang/include/clang/Basic/SourceLocation.h
index 00b1e0fa855b7a..7a0f5ba8d1270b 100644
--- a/clang/include/clang/Basic/SourceLocation.h
+++ b/clang/include/clang/Basic/SourceLocation.h
@@ -90,6 +90,7 @@ class SourceLocation {
   friend class ASTWriter;
   friend class SourceManager;
   friend struct llvm::FoldingSetTrait;
+  friend class SourceLocationEncoding;
 
 public:
   using UIntTy = uint32_t;
diff --git a/clang/include/clang/Serialization/ASTBitCodes.h 
b/clang/include/clang/Serialization/ASTBitCodes.h
index f31efa5117f0d1..8ccf098d4eb549 100644
--- a/clang/include/clang/Serialization/ASTBitCodes.h
+++ b/clang/include/clang/Serialization/ASTBitCodes.h
@@ -22,6 +22,7 @@
 #include "clang/Basic/IdentifierTable.h"
 #include "clang/Basic/OperatorKinds.h"
 #include "clang/Basic/SourceLocation.h"
+#include "clang/Serialization/SourceLocationEncoding.h"
 #include "llvm/ADT/DenseMapInfo.h"
 #include "llvm/Bitstream/BitCodes.h"
 #include 
@@ -175,44 +176,47 @@ const unsigned int NUM_PREDEF_SUBMODULE_IDS = 1;
 
 /// Source range/offset of a preprocessed entity.
 struct PPEntityOffset {
+  using RawLocEncoding = SourceLocationEncoding::RawLocEncoding;
+
   /// Raw source location of beginning of range.
-  SourceLocation::UIntTy Begin;
+  RawLocEncoding Begin;
 
   /// Raw source location of end of range.
-  SourceLocation::UIntTy End;
+  RawLocEncoding End;
 
   /// Offset in the AST file relative to ModuleFile::MacroOffsetsBase.
   uint32_t BitOffset;
 
-  PPEntityOffset(SourceRange R, uint32_t BitOffset)
-  : Begin(R.getBegin().getRawEncoding()), End(R.getEnd().getRawEncoding()),
+  PPEntityOffset(RawLocEncoding Begin, RawLocEncoding End, uint32_t BitOffset)
+  : Begin(Begin), End(End),
 BitOffset(BitOffset) {}
 
-  SourceLocation getBegin() const {
-return SourceLocation::getFromRawEncoding(Begin);
+  RawLocEncoding getBegin() const {
+return Begin;
   }
-
-  SourceLocation getEnd() const {
-return SourceLocation::getFromRawEncoding(End);
+  RawLocEncoding getEnd() const {
+return End;
   }
 };
 
 /// Source range of a skipped preprocessor region
 struct PPSkippedRange {
+  using RawLocEncoding = SourceLocationEncoding::RawLocEncoding;
+
   /// Raw source location of beginning of range.
-  SourceLocation::UIntTy Begin;
+  RawLocEncoding Begin;
   /// Raw source location of end of range.
-  SourceLocation::UIntTy End;
+  RawLocEncoding End;
 
-  PPSkippedRange(SourceRange R)
-  : Begin(R.getBegin().getRawEncoding()), End(R.getEnd().getRawEncoding()) 
{
+  PPSkippedRange(RawLocEncoding Begin, RawLocEncoding End)
+  : Begin(Begin), End(End) {
   }
 
-  SourceLocation getBegin() const {
-return SourceLocation::getFromRawEncoding(Begin);
+  RawLocEncoding getBegin() const {
+return Begin;
   }
-  SourceLocation getEnd() const {
-return SourceLocation::getFromRawEncoding(End);
+  RawLocEncoding getEnd() const {
+return End;
   }
 };
 
@@ -239,8 +243,10 @@ struct UnderalignedInt64 {
 
 /// Source location and bit offset of a declaration.
 struct DeclOffset {
+  using RawLocEncoding = SourceLocationEncoding::RawLocEncoding;
+
   /// Raw source location.
-  SourceLocation::UIntTy Loc = 0;
+  RawLocEncoding RawLoc = 0;
 
   /// Offset relative to the start of the DECLTYPES_BLOCK block. Keep
   /// structure alignment 32-bit and avoid padding gap because undefined
@@ -248,16 +254,17 @@ struct DeclOffset {
   UnderalignedInt64 BitOffset;
 
   DeclOffset() = default;
-  DeclOffset(SourceLocation Loc, uint64_t BitOffset,
- uint64_t 

[clang] [C++20] [Modules] Introduce -fmodules-reduced-bmi (PR #85050)

2024-03-26 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

> > > > @iains @dwblaikie Understood. And I thought the major problem is that 
> > > > there are a lot flags from clang modules. And it is indeed confusing. 
> > > > But given we have to introduce new flags in this case, probably we can 
> > > > only try to make it more clear by better documents.
> > > 
> > > 
> > > So you do not think it possible to restrict the new flag to be "internal" 
> > > (i.e. cc1-only) and to put some _temporary_ driver processing to handle 
> > > that? (I agree that this is an unusual mechanism, but the idea is to 
> > > recognise that the driver-side processing is only expected to me 
> > > temporary).
> > 
> > 
> > I have no idea how can we make that. We still need the users to provide 
> > something to enable reduced BMI. And I think it is symmetric to a new flag.
> 
> What I mean is that (a) we need the internal 'cc1' flag permanently; but (b) 
> we do not expect to need a user-facing driver flag permanently. and (c) We 
> want to allow users to try this out.
> 
> I am suggesting we could say "to try this out use -Xclang 
> -fmodules-reduced-bmi" and have _temporary_ code in the driver to deal with 
> the changes needed to phasing.
> 
> If this is not possible. then I suppose I am a bit sad that we keep saying 
> 'there are too many modules options' - but yet still add more. however - we 
> need to make progress, so if the suggestion here is really a non-starter .. 
> then such is life.
> 
> Perhaps the second suggestion (-fexperimental-x options) could be 
> discussed at the project level.

Got your point. But I feel the `-Xclang xxx` style or the `-fexperimental-xxx` 
style may make people feel, "oh, this is not ready, let's wait". Then we may 
lose more testing opportunity. Also I feel such options are symmetric to the 
existing one. It still makes the interfaces to be more complicated. I don't 
feel they are better than the existing one.

And yes, it is indeed that we have a lot modules options. But I think this may 
not be the blocking point for adding new modules options if we think it is 
really needed. If there are things needed to be added by flags really and we 
don't do that due to we feel we have too many flags, I feel it is somewhat "not 
eating for fear of choking". I think what we need to do for this case is to be 
pretty careful when adding new flags and I think we already make it for Reduced 
BMI.

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


[clang] [Clang] Coroutines: Properly Check if `await_suspend` return type is a `std::coroutine_handle` (PR #85684)

2024-03-26 Thread Chuanqi Xu via cfe-commits


@@ -418,39 +448,60 @@ static ReadySuspendResumeResult buildCoawaitCalls(Sema 
, VarDecl *CoroPromise,
 return Calls;
   }
   Expr *CoroHandle = CoroHandleRes.get();
-  CallExpr *AwaitSuspend = cast_or_null(
-  BuildSubExpr(ACT::ACT_Suspend, "await_suspend", CoroHandle));
+  auto *AwaitSuspend = [&]() -> CallExpr * {
+auto *SubExpr = BuildSubExpr(ACT::ACT_Suspend, "await_suspend", 
CoroHandle);
+if (!SubExpr)
+  return nullptr;
+if (auto *E = dyn_cast(SubExpr)) {
+  // This happens when await_suspend return type is not trivially
+  // destructible. This doesn't happen for the permitted return types of
+  // such function. Diagnose it later.
+  return cast_or_null(E->getSubExpr());
+} else {
+  return cast_or_null(SubExpr);
+}

ChuanqiXu9 wrote:

Thanks. My motivation is that the small pattern match style looks really not 
good. And if it is possible to get the RecordDecl by the type of `Operand` and 
find the `await_suspend` member function? If yes, we can still get the location 
of `await_suspend`.

And if we have problems printing `(have 'Status')` part, I feel it may not be a 
big problem since the underlying issue is clear.

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


[clang] [C++20] [Modules] Introduce -fmodules-reduced-bmi (PR #85050)

2024-03-25 Thread Chuanqi Xu via cfe-commits

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


[clang] [C++20] [Modules] Introduce -fmodules-reduced-bmi (PR #85050)

2024-03-25 Thread Chuanqi Xu via cfe-commits

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


[clang] [C++20] [Modules] Introduce -fgen-reduced-bmi (PR #85050)

2024-03-25 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

> Do I miss something? The performance and file size is similar with and 
> without `-fgen-reduced-bmi`. To reproduce clone 
> https://github.com/koplas/clang-modules-test and run `build.sh` and 
> `build_thin_bmi.sh`.

Currently, the Reduced BMI will only remove function bodies for non-inline 
functions and definitions for some variables...

And declarations in headers or GMF are primarily inline, so probably the 
current Reduced BMI won't produce a strong impact on modules whose contents are 
primarily in GMF as expectedly.

For example, I can observe some impact on 
https://github.com/alibaba/async_simple/tree/CXX20Modules, where the repo has 
more use codes in the module purview instead of the GMF.

Further, in my mind, we can reduce more things in Reduced BMI. An example may 
be https://github.com/llvm/llvm-project/pull/76930.

Thanks for testing : )

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


[clang] [C++20] [Modules] Introduce -fgen-reduced-bmi (PR #85050)

2024-03-25 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

> Using `-fgen-reduced-bmi` currently fails for me with a case that looks like 
> this:
> 
> ```c++
> // a.hpp
>   template 
>   void ignore(T const &) noexcept {}
>   
>   inline void resultCheck(char const *message) {
>   ignore(message);
>   }
>   
> // b.cppm
> module;
> #include "a.hpp"
> export module b;
> 
> export {
> using ignore;
> using resultCheck;
> }
> 
> // c.cppm
> export module c;
> import b;
> 
> export void test() {
> resultCheck(nullptr);
> }
> ```
> 
> This will result in this linker error: `undefined reference to void 
> ignore(char const* const&)`. Removing `-fgen-reduced-bmi` will 
> result in linking without errors. Do I need to pass certain flags to CMake?

This may be fixed in trunk. This should be a bug in Reduced BMI. Note that the 
current patch is only the driver part of Reduced BMI. And this is the reason 
why we need a new flag. Otherwise I'll propose to enable it by default : )

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


[clang] [C++20] [Modules] Introduce -fgen-reduced-bmi (PR #85050)

2024-03-25 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

@iains @dwblaikie Understood. And I thought the major problem is that there are 
a lot flags from clang modules. And it is indeed confusing. But given we have 
to introduce new flags in this case, probably we can only try to make it more 
clear by better documents.

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


[clang] [C++20] [Modules] Introduce -fgen-reduced-bmi (PR #85050)

2024-03-25 Thread Chuanqi Xu via cfe-commits


@@ -3031,6 +3032,11 @@ defm skip_odr_check_in_gmf : BoolOption<"f", 
"skip-odr-check-in-gmf",
   "Perform ODR checks for decls in the global module fragment.">>,
   Group;
 
+def gen_reduced_bmi : Flag<["-"], "fgen-reduced-bmi">,

ChuanqiXu9 wrote:

Done by using `-fmodules-reduce-bmi`

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


[clang] [C++20] [Modules] Introduce -fgen-reduced-bmi (PR #85050)

2024-03-25 Thread Chuanqi Xu via cfe-commits


@@ -0,0 +1,53 @@
+// It is annoying to handle different slash direction
+// in Windows and Linux. So we disable the test on Windows
+// here.
+// REQUIRES: !system-windows

ChuanqiXu9 wrote:

Done

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


[clang] [C++20] [Modules] Introduce -fgen-reduced-bmi (PR #85050)

2024-03-25 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 updated 
https://github.com/llvm/llvm-project/pull/85050

>From 5fcccd75d0823ff11a4e385565cad65034d0def7 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu 
Date: Tue, 12 Mar 2024 17:26:49 +0800
Subject: [PATCH 1/2] [C++20] [Modules] Introduce -fgen-reduced-bmi

---
 clang/include/clang/CodeGen/CodeGenAction.h   |  2 +
 clang/include/clang/Driver/Options.td |  6 +++
 .../include/clang/Frontend/FrontendOptions.h  |  9 +++-
 clang/include/clang/Serialization/ASTWriter.h |  7 +--
 clang/lib/CodeGen/CodeGenAction.cpp   | 19 +++
 clang/lib/Driver/Driver.cpp   | 27 +-
 clang/lib/Driver/ToolChains/Clang.cpp | 41 --
 clang/lib/Driver/ToolChains/Clang.h   | 14 +
 clang/lib/Frontend/FrontendActions.cpp|  7 +++
 clang/lib/Frontend/PrecompiledPreamble.cpp|  3 +-
 clang/lib/Serialization/GeneratePCH.cpp   | 23 ++--
 .../test/Driver/module-fgen-reduced-bmi.cppm  | 53 +++
 clang/test/Modules/gen-reduced-bmi.cppm   | 36 +
 13 files changed, 220 insertions(+), 27 deletions(-)
 create mode 100644 clang/test/Driver/module-fgen-reduced-bmi.cppm
 create mode 100644 clang/test/Modules/gen-reduced-bmi.cppm

diff --git a/clang/include/clang/CodeGen/CodeGenAction.h 
b/clang/include/clang/CodeGen/CodeGenAction.h
index 7ad2988e589eb2..186dbb43f01ef7 100644
--- a/clang/include/clang/CodeGen/CodeGenAction.h
+++ b/clang/include/clang/CodeGen/CodeGenAction.h
@@ -57,6 +57,8 @@ class CodeGenAction : public ASTFrontendAction {
   bool loadLinkModules(CompilerInstance );
 
 protected:
+  bool BeginSourceFileAction(CompilerInstance ) override;
+
   /// Create a new code generation action.  If the optional \p _VMContext
   /// parameter is supplied, the action uses it without taking ownership,
   /// otherwise it creates a fresh LLVM context and takes ownership.
diff --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index b0d90c776b58a9..0eca2a95e3271e 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -3017,6 +3017,7 @@ defm prebuilt_implicit_modules : 
BoolFOption<"prebuilt-implicit-modules",
 
 def fmodule_output_EQ : Joined<["-"], "fmodule-output=">,
   Flags<[NoXarchOption]>, Visibility<[ClangOption, CC1Option]>,
+  MarshallingInfoString>,
   HelpText<"Save intermediate module file results when compiling a standard 
C++ module unit.">;
 def fmodule_output : Flag<["-"], "fmodule-output">, Flags<[NoXarchOption]>,
   Visibility<[ClangOption, CC1Option]>,
@@ -3030,6 +3031,11 @@ defm skip_odr_check_in_gmf : BoolOption<"f", 
"skip-odr-check-in-gmf",
   "Perform ODR checks for decls in the global module fragment.">>,
   Group;
 
+def gen_reduced_bmi : Flag<["-"], "fgen-reduced-bmi">,
+  Group, Visibility<[ClangOption, CC1Option]>,
+  HelpText<"Generate the reduced BMI">,
+  MarshallingInfoFlag>;
+
 def fmodules_prune_interval : Joined<["-"], "fmodules-prune-interval=">, 
Group,
   Visibility<[ClangOption, CC1Option]>, MetaVarName<"">,
   HelpText<"Specify the interval (in seconds) between attempts to prune the 
module cache">,
diff --git a/clang/include/clang/Frontend/FrontendOptions.h 
b/clang/include/clang/Frontend/FrontendOptions.h
index 8085dbcbf671a6..ddfd4f30d1b773 100644
--- a/clang/include/clang/Frontend/FrontendOptions.h
+++ b/clang/include/clang/Frontend/FrontendOptions.h
@@ -387,6 +387,10 @@ class FrontendOptions {
   LLVM_PREFERRED_TYPE(bool)
   unsigned ModulesShareFileManager : 1;
 
+  /// Whether to generate reduced BMI for C++20 named modules.
+  LLVM_PREFERRED_TYPE(bool)
+  unsigned GenReducedBMI : 1;
+
   CodeCompleteOptions CodeCompleteOpts;
 
   /// Specifies the output format of the AST.
@@ -553,6 +557,9 @@ class FrontendOptions {
   /// Path which stores the output files for -ftime-trace
   std::string TimeTracePath;
 
+  /// Output Path for module output file.
+  std::string ModuleOutputPath;
+
 public:
   FrontendOptions()
   : DisableFree(false), RelocatablePCH(false), ShowHelp(false),
@@ -565,7 +572,7 @@ class FrontendOptions {
 BuildingImplicitModuleUsesLock(true), ModulesEmbedAllFiles(false),
 IncludeTimestamps(true), UseTemporary(true),
 AllowPCMWithCompilerErrors(false), ModulesShareFileManager(true),
-TimeTraceGranularity(500) {}
+GenReducedBMI(false), TimeTraceGranularity(500) {}
 
   /// getInputKindForExtension - Return the appropriate input kind for a file
   /// extension. For example, "c" would return Language::C.
diff --git a/clang/include/clang/Serialization/ASTWriter.h 
b/clang/include/clang/Serialization/ASTWriter.h
index 3ed9803fa3745b..bd310b6c7a5cdd 100644
--- a/clang/include/clang/Serialization/ASTWriter.h
+++ b/clang/include/clang/Serialization/ASTWriter.h
@@ -846,7 +846,7 @@ class ASTWriter : public ASTDeserializationListener,
 /// AST and semantic-analysis consumer that generates a
 /// precompiled header from the 

[clang] [Clang] Coroutines: Properly Check if `await_suspend` return type is a `std::coroutine_handle` (PR #85684)

2024-03-25 Thread Chuanqi Xu via cfe-commits


@@ -418,39 +448,60 @@ static ReadySuspendResumeResult buildCoawaitCalls(Sema 
, VarDecl *CoroPromise,
 return Calls;
   }
   Expr *CoroHandle = CoroHandleRes.get();
-  CallExpr *AwaitSuspend = cast_or_null(
-  BuildSubExpr(ACT::ACT_Suspend, "await_suspend", CoroHandle));
+  auto *AwaitSuspend = [&]() -> CallExpr * {
+auto *SubExpr = BuildSubExpr(ACT::ACT_Suspend, "await_suspend", 
CoroHandle);
+if (!SubExpr)
+  return nullptr;
+if (auto *E = dyn_cast(SubExpr)) {
+  // This happens when await_suspend return type is not trivially
+  // destructible. This doesn't happen for the permitted return types of
+  // such function. Diagnose it later.
+  return cast_or_null(E->getSubExpr());
+} else {
+  return cast_or_null(SubExpr);
+}

ChuanqiXu9 wrote:

I am still concerning the change. What's the type of `SubExpr`? Can we get the 
return type of SubExpr directly instead of accessing it by CallExpr?

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


[clang] [Clang] [C++26] Implement P2573R2: `= delete("should have a reason");` (PR #86526)

2024-03-25 Thread Chuanqi Xu via cfe-commits


@@ -761,6 +761,13 @@ void ASTDeclWriter::VisitFunctionDecl(FunctionDecl *D) {
 }
   }
 
+  // FIXME: Hack: We're out of bits in FunctionDeclBits, so always
+  // add this even though it's 0 in the vast majority of cases. We
+  // might really want to consider storing this in the DefaultedFunctionInfo
+  // instead.
+  if (D->isDeletedAsWritten())
+Record.AddStmt(D->getDeletedMessage());

ChuanqiXu9 wrote:

I didn't understand. Since the string literal is required to be `unevaluated 
string`, I feel it may be good to record the string value directly by 
`StringLiteral::getBytes`.

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


[clang] [Clang] Coroutines: Properly Check if `await_suspend` return type is a `std::coroutine_handle` (PR #85684)

2024-03-22 Thread Chuanqi Xu via cfe-commits


@@ -418,39 +448,60 @@ static ReadySuspendResumeResult buildCoawaitCalls(Sema 
, VarDecl *CoroPromise,
 return Calls;
   }
   Expr *CoroHandle = CoroHandleRes.get();
-  CallExpr *AwaitSuspend = cast_or_null(
-  BuildSubExpr(ACT::ACT_Suspend, "await_suspend", CoroHandle));
+  auto *AwaitSuspend = [&]() -> CallExpr * {
+auto *SubExpr = BuildSubExpr(ACT::ACT_Suspend, "await_suspend", 
CoroHandle);
+if (!SubExpr)
+  return nullptr;
+if (auto *E = dyn_cast(SubExpr)) {
+  // This happens when await_suspend return type is not trivially
+  // destructible. This doesn't happen for the permitted return types of
+  // such function. Diagnose it later.
+  return cast_or_null(E->getSubExpr());
+} else {
+  return cast_or_null(SubExpr);
+}

ChuanqiXu9 wrote:

I mean, how about diagnose `InvalidAwaitSuspendReturnType` directly if it is 
null. And we can use `dyn_cast_if_present` instead of `cast_or_null`. WDYT?

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


[clang] [Clang] Coroutines: Properly Check if `await_suspend` return type is a `std::coroutine_handle` (PR #85684)

2024-03-22 Thread Chuanqi Xu via cfe-commits


@@ -418,39 +448,60 @@ static ReadySuspendResumeResult buildCoawaitCalls(Sema 
, VarDecl *CoroPromise,
 return Calls;
   }
   Expr *CoroHandle = CoroHandleRes.get();
-  CallExpr *AwaitSuspend = cast_or_null(
-  BuildSubExpr(ACT::ACT_Suspend, "await_suspend", CoroHandle));
+  auto *AwaitSuspend = [&]() -> CallExpr * {
+auto *SubExpr = BuildSubExpr(ACT::ACT_Suspend, "await_suspend", 
CoroHandle);
+if (!SubExpr)
+  return nullptr;
+if (auto *E = dyn_cast(SubExpr)) {
+  // This happens when await_suspend return type is not trivially
+  // destructible. This doesn't happen for the permitted return types of
+  // such function. Diagnose it later.
+  return cast_or_null(E->getSubExpr());
+} else {
+  return cast_or_null(SubExpr);
+}

ChuanqiXu9 wrote:

I don't understand why we need to do this here. Can't it be handled by the 
following check?

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


[clang] [Clang] Coroutines: Properly Check if `await_suspend` return type is a `std::coroutine_handle` (PR #85684)

2024-03-22 Thread Chuanqi Xu via cfe-commits


@@ -339,6 +339,9 @@ Bug Fixes in This Version
 - Fixes an assertion failure on invalid code when trying to define member
   functions in lambdas.
 
+- Clang now emits errors for coroutine `await_suspend` functions whose return 
type is not
+  one of `void`, `bool`, or `std::coroutine_handle`.

ChuanqiXu9 wrote:

Maybe we should move this to `Potential Breaking Section` and mention it 
conforms the standard wording.


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


[clang] [Clang] Coroutines: Properly Check if `await_suspend` return type is a `std::coroutine_handle` (PR #85684)

2024-03-22 Thread Chuanqi Xu via cfe-commits


@@ -358,6 +364,30 @@ static Expr *maybeTailCall(Sema , QualType RetType, Expr 
*E,
   return S.MaybeCreateExprWithCleanups(JustAddress);
 }
 
+static bool isSpecializationOfCoroutineHandle(Sema , QualType Ty,
+  SourceLocation Loc) {
+  auto *CoroutineHandleClassTemplateDecl =
+  lookupCoroutineHandleTemplate(S, Loc);

ChuanqiXu9 wrote:

Maybe it can be better to cache the coroutine handle declaration to avoid 
redundant looking up. But it may be fine for the number of `await_suspend` in 
practical.

We can send another patch for this if we want.

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


[clang] [clang] Improves -print-library-module-manifest-path. (PR #85943)

2024-03-21 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 approved this pull request.

LGTM

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


[clang] [Clang] Coroutines: Properly Check if `await_suspend` return type convertible to `std::coroutine_handle<>` (PR #85684)

2024-03-20 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

> > I am confused. If we don't need to check whether a type can be converted to 
> > std::coroutine_handle, why do we still need EvaluateBinaryTypeTraits or 
> > similar things.
> 
> I thought your previous comment was to show concern about exposing 
> `EvaluateBinaryTypeTraits` contained a bunch of nonfunctional changes.

Yes, this is the intention.

> Do you think it's good?

For the issue we have, it is not. We're introducing a lot of nonfunctional 
change for a non-standard and unimportant feature... So I may feel better if we 
can avoid that.


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


[clang] [Clang] Coroutines: Properly Check if `await_suspend` return type convertible to `std::coroutine_handle<>` (PR #85684)

2024-03-20 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

> In SemaExprCXX.cpp there's EvaluateBinaryTypeTraits that I needed to expose 
> as suggested by the comment in SemaCoroutine. Is there an alternative way to 
> do type coercion/equivalence checks?

I am confused. If we don't need to check whether a type can be converted to 
`std::coroutine_handle`, why do we still need EvaluateBinaryTypeTraits or 
similar things.

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


[clang] [clang][frontend] Make DumpModuleInfoAction emit the full macro (PR #85745)

2024-03-20 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 commented:

Dumping things from the source location makes me nervous... And giving this is 
not related to named modules, I'd like to leave this for @Bigcheese 

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


[clang] [llvm] [Coroutines] Drop dead instructions more aggressively in addMustTailToCoroResumes() (PR #85271)

2024-03-20 Thread Chuanqi Xu via cfe-commits


@@ -0,0 +1,65 @@
+// This tests that the symmetric transfer at the final suspend point could 
happen successfully.

ChuanqiXu9 wrote:

nit: I feel slightly better to add a link to the github page.

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


[clang] [llvm] [Coroutines] Drop dead instructions more aggressively in addMustTailToCoroResumes() (PR #85271)

2024-03-20 Thread Chuanqi Xu via cfe-commits

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


[clang] [llvm] [Coroutines] Drop dead instructions more aggressively in addMustTailToCoroResumes() (PR #85271)

2024-03-20 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 approved this pull request.

LGTM. Thanks.

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


[clang] Reland Print library module manifest path again (PR #84881)

2024-03-19 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

> > > > > The file we're looking for is `modules.json`; Renaming it 
> > > > > `libc++.modules.json` like `.so` / `.a` file might be a better idea 
> > > > > which could avoid name clashes when installed in `/usr/lib`.
> > > > 
> > > > 
> > > > but i didn't rename it, it was with the libc++ prefix directly :/
> > > 
> > > 
> > > Good point I did :-/ It seems we originally talked about `modules.json` 
> > > and later mentioned using the libname. @ChuanqiXu9 I prefer to keep the 
> > > current name `libc++.modules.json` and adjust clang. WDYT?
> > 
> > 
> > Could you elaborate the reason more? I feel like renaming 
> > `libc++.modules.json` to `modules.json` is straightforward. Maybe I didn't 
> > take part it in the old disscussion or I missed : )
> 
> It would allow to install libstdc++ and libc++ in the same lib directory 
> without "fighting" who owns `modules.json`. Also if we want to provide 
> `libc++-asan.so` in the future we can provide `libc++-asan.modules.json`. 
> Whether we need a different `module.json` for ASan is unknown at the moment, 
> but I can imagine we have additional compiler or linker flags for ASan.

h, I can accept that. Then the patch itself is not incorrect... Since it 
looks like we'd never look for `modules.json` actually, right? Let's adjust the 
implementation in clang.

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


[clang] [Clang] Coroutines: Properly Check if `await_suspend` return type convertible to `std::coroutine_handle<>` (PR #85684)

2024-03-19 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

> I am also ok with changing the patch to reject programs whose await_suspend 
> doesn't strictly return std::coroutine_handle if upstream prefers.

It should be good to do that since it makes the behavior more conforming. And 
maybe it is better to do this a seperate patch.
Especially if it can help reduce the many non-semantical changes in 
SemaExprCXX.cpp.



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


[clang] Reland Print library module manifest path again (PR #84881)

2024-03-18 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

> > > The file we're looking for is `modules.json`; Renaming it 
> > > `libc++.modules.json` like `.so` / `.a` file might be a better idea which 
> > > could avoid name clashes when installed in `/usr/lib`.
> > 
> > 
> > but i didn't rename it, it was with the libc++ prefix directly :/
> 
> Good point I did :-/ It seems we originally talked about `modules.json` and 
> later mentioned using the libname. @ChuanqiXu9 I prefer to keep the current 
> name `libc++.modules.json` and adjust clang. WDYT?

Could you elaborate the reason more? I feel like renaming `libc++.modules.json` 
to `modules.json` is straightforward. Maybe I didn't take part it in the old 
disscussion or I missed : )

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


[clang] Reland Print library module manifest path again (PR #84881)

2024-03-18 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

/cherry-pick 0e1e1fc8f0e

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


[clang] Reland Print library module manifest path again (PR #84881)

2024-03-18 Thread Chuanqi Xu via cfe-commits

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


[clang] Reland Print library module manifest path again (PR #84881)

2024-03-17 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

> The file we're looking for is `modules.json`; Renaming it 
> `libc++.modules.json` like `.so` / `.a` file might be a better idea which 
> could avoid name clashes when installed in `/usr/lib`.

BTW, how do you feel about the paragraph. I thought it as a defect in some 
level.

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


[clang] Reland Print library module manifest path again (PR #84881)

2024-03-17 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

I'll backport this tomorrow if no revert request shows up.

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


[clang] Reland Print library module manifest path again (PR #84881)

2024-03-17 Thread Chuanqi Xu via cfe-commits

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


[clang] 2582965 - [C++20] [Modules] [Reduced BMI] Generate the function body from implicitly instantiated class and constant variables

2024-03-14 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2024-03-14T15:07:08+08:00
New Revision: 2582965c160486f9e3b0680f1cebc5ffdef9620c

URL: 
https://github.com/llvm/llvm-project/commit/2582965c160486f9e3b0680f1cebc5ffdef9620c
DIFF: 
https://github.com/llvm/llvm-project/commit/2582965c160486f9e3b0680f1cebc5ffdef9620c.diff

LOG: [C++20] [Modules] [Reduced BMI] Generate the function body from implicitly 
instantiated class and constant variables

After this patch, we will generate the function body from implicitly
instantiated class. This is important for consumers with same
template arguments. Otherwise the consumers won't see the function body.
Since the consumers won't instantiate the templates again if they find an
instantiation.

Also we will generate the variable definition if the variable is
non-inline but known as constant. Such variables may not affect the
ABI, but they may get involved into the compile time constant computation
in the consumer's code. So we have to generate such definitions.

Added: 
clang/test/Modules/reduced-bmi-generating-codes.cppm

Modified: 
clang/lib/Serialization/ASTWriterDecl.cpp

Removed: 




diff  --git a/clang/lib/Serialization/ASTWriterDecl.cpp 
b/clang/lib/Serialization/ASTWriterDecl.cpp
index d04e1c781b4e28..86f64bf2a24250 100644
--- a/clang/lib/Serialization/ASTWriterDecl.cpp
+++ b/clang/lib/Serialization/ASTWriterDecl.cpp
@@ -281,11 +281,18 @@ bool clang::CanElideDeclDef(const Decl *D) {
 
 if (FD->isDependentContext())
   return false;
+
+if (FD->getTemplateSpecializationKind() == TSK_ImplicitInstantiation)
+  return false;
   }
 
   if (auto *VD = dyn_cast(D)) {
 if (!VD->getDeclContext()->getRedeclContext()->isFileContext() ||
-VD->isInline() || VD->isConstexpr() || isa(VD))
+VD->isInline() || VD->isConstexpr() || isa(VD) ||
+// Constant initialized variable may not affect the ABI, but they
+// may be used in constant evaluation in the frontend, so we have
+// to remain them.
+VD->hasConstantInitialization())
   return false;
 
 if (VD->getTemplateSpecializationKind() == TSK_ImplicitInstantiation)

diff  --git a/clang/test/Modules/reduced-bmi-generating-codes.cppm 
b/clang/test/Modules/reduced-bmi-generating-codes.cppm
new file mode 100644
index 00..13dcda06437b29
--- /dev/null
+++ b/clang/test/Modules/reduced-bmi-generating-codes.cppm
@@ -0,0 +1,40 @@
+// Although the reduced BMI are not designed to be generated,
+// it is helpful for testing whether we've reduced the definitions.
+//
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+//
+// RUN: %clang_cc1 -std=c++20 -triple %itanium_abi_triple %t/a.cppm \
+// RUN: -emit-reduced-module-interface -o %t/a.pcm
+// RUN: %clang_cc1 -std=c++20 -triple %itanium_abi_triple %t/b.cpp \
+// RUN: -fmodule-file=a=%t/a.pcm -S -emit-llvm -o - \
+// RUN: | FileCheck %t/b.cpp
+
+//--- a.cppm
+export module a;
+
+export template 
+class A {
+public:
+int member() {
+return 43;
+}
+};
+
+// Instantiate `A::member()`.
+export int a_member = A().member();
+
+export const int a = 43;
+
+//--- b.cpp
+import a;
+
+static_assert(a == 43);
+
+int b() {
+A a;
+return a.member();
+}
+
+// CHECK: define{{.*}}@_ZNW1a1AIiE6memberEv



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [C++20] [Modules] Introduce -fgen-reduced-bmi (PR #85050)

2024-03-13 Thread Chuanqi Xu via cfe-commits

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


[clang] [C++20] [Modules] Introduce -fgen-reduced-bmi (PR #85050)

2024-03-13 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 updated 
https://github.com/llvm/llvm-project/pull/85050

>From e5114cdc6a77711dda6a13cbee9cd5cc42be48c6 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu 
Date: Tue, 12 Mar 2024 17:26:49 +0800
Subject: [PATCH] [C++20] [Modules] Introduce -fgen-reduced-bmi

---
 clang/include/clang/CodeGen/CodeGenAction.h   |  2 +
 clang/include/clang/Driver/Options.td |  6 +++
 .../include/clang/Frontend/FrontendOptions.h  |  9 +++-
 clang/include/clang/Serialization/ASTWriter.h |  7 +--
 clang/lib/CodeGen/CodeGenAction.cpp   | 19 +++
 clang/lib/Driver/Driver.cpp   | 27 +-
 clang/lib/Driver/ToolChains/Clang.cpp | 41 --
 clang/lib/Driver/ToolChains/Clang.h   | 14 +
 clang/lib/Frontend/FrontendActions.cpp|  7 +++
 clang/lib/Frontend/PrecompiledPreamble.cpp|  3 +-
 clang/lib/Serialization/GeneratePCH.cpp   | 23 ++--
 .../test/Driver/module-fgen-reduced-bmi.cppm  | 53 +++
 clang/test/Modules/gen-reduced-bmi.cppm   | 36 +
 13 files changed, 220 insertions(+), 27 deletions(-)
 create mode 100644 clang/test/Driver/module-fgen-reduced-bmi.cppm
 create mode 100644 clang/test/Modules/gen-reduced-bmi.cppm

diff --git a/clang/include/clang/CodeGen/CodeGenAction.h 
b/clang/include/clang/CodeGen/CodeGenAction.h
index 7ad2988e589eb2..186dbb43f01ef7 100644
--- a/clang/include/clang/CodeGen/CodeGenAction.h
+++ b/clang/include/clang/CodeGen/CodeGenAction.h
@@ -57,6 +57,8 @@ class CodeGenAction : public ASTFrontendAction {
   bool loadLinkModules(CompilerInstance );
 
 protected:
+  bool BeginSourceFileAction(CompilerInstance ) override;
+
   /// Create a new code generation action.  If the optional \p _VMContext
   /// parameter is supplied, the action uses it without taking ownership,
   /// otherwise it creates a fresh LLVM context and takes ownership.
diff --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index aca8c9b0d5487a..b8ceeff9362df9 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -3018,6 +3018,7 @@ defm prebuilt_implicit_modules : 
BoolFOption<"prebuilt-implicit-modules",
 
 def fmodule_output_EQ : Joined<["-"], "fmodule-output=">,
   Flags<[NoXarchOption]>, Visibility<[ClangOption, CC1Option]>,
+  MarshallingInfoString>,
   HelpText<"Save intermediate module file results when compiling a standard 
C++ module unit.">;
 def fmodule_output : Flag<["-"], "fmodule-output">, Flags<[NoXarchOption]>,
   Visibility<[ClangOption, CC1Option]>,
@@ -3031,6 +3032,11 @@ defm skip_odr_check_in_gmf : BoolOption<"f", 
"skip-odr-check-in-gmf",
   "Perform ODR checks for decls in the global module fragment.">>,
   Group;
 
+def gen_reduced_bmi : Flag<["-"], "fgen-reduced-bmi">,
+  Group, Visibility<[ClangOption, CC1Option]>,
+  HelpText<"Generate the reduced BMI">,
+  MarshallingInfoFlag>;
+
 def fmodules_prune_interval : Joined<["-"], "fmodules-prune-interval=">, 
Group,
   Visibility<[ClangOption, CC1Option]>, MetaVarName<"">,
   HelpText<"Specify the interval (in seconds) between attempts to prune the 
module cache">,
diff --git a/clang/include/clang/Frontend/FrontendOptions.h 
b/clang/include/clang/Frontend/FrontendOptions.h
index 8085dbcbf671a6..ddfd4f30d1b773 100644
--- a/clang/include/clang/Frontend/FrontendOptions.h
+++ b/clang/include/clang/Frontend/FrontendOptions.h
@@ -387,6 +387,10 @@ class FrontendOptions {
   LLVM_PREFERRED_TYPE(bool)
   unsigned ModulesShareFileManager : 1;
 
+  /// Whether to generate reduced BMI for C++20 named modules.
+  LLVM_PREFERRED_TYPE(bool)
+  unsigned GenReducedBMI : 1;
+
   CodeCompleteOptions CodeCompleteOpts;
 
   /// Specifies the output format of the AST.
@@ -553,6 +557,9 @@ class FrontendOptions {
   /// Path which stores the output files for -ftime-trace
   std::string TimeTracePath;
 
+  /// Output Path for module output file.
+  std::string ModuleOutputPath;
+
 public:
   FrontendOptions()
   : DisableFree(false), RelocatablePCH(false), ShowHelp(false),
@@ -565,7 +572,7 @@ class FrontendOptions {
 BuildingImplicitModuleUsesLock(true), ModulesEmbedAllFiles(false),
 IncludeTimestamps(true), UseTemporary(true),
 AllowPCMWithCompilerErrors(false), ModulesShareFileManager(true),
-TimeTraceGranularity(500) {}
+GenReducedBMI(false), TimeTraceGranularity(500) {}
 
   /// getInputKindForExtension - Return the appropriate input kind for a file
   /// extension. For example, "c" would return Language::C.
diff --git a/clang/include/clang/Serialization/ASTWriter.h 
b/clang/include/clang/Serialization/ASTWriter.h
index 3ed9803fa3745b..bd310b6c7a5cdd 100644
--- a/clang/include/clang/Serialization/ASTWriter.h
+++ b/clang/include/clang/Serialization/ASTWriter.h
@@ -846,7 +846,7 @@ class ASTWriter : public ASTDeserializationListener,
 /// AST and semantic-analysis consumer that generates a
 /// precompiled header from the 

[clang] [C++20] [Modules] Introduce -fgen-reduced-bmi (PR #85050)

2024-03-13 Thread Chuanqi Xu via cfe-commits

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


[clang] [C++20] [Modules] Introduce -fgen-reduced-bmi (PR #85050)

2024-03-13 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 created 
https://github.com/llvm/llvm-project/pull/85050

This is the driver part of https://github.com/llvm/llvm-project/pull/75894.

This patch introduces '-fgen-reduced-bmi' to enable generating the reduced BMI.

This patch did:
- When `-fgen-reduced-bmi` is specified but `--precompile` is not specified for 
a module unit, we'll skip the precompile phase to avoid unnecessary  two-phase 
compilation phases. Then if `-c` is specified, we will generate the reduced BMI 
in CodeGenAction as a by-product.
- When `-fgen-reduced-bmi` is specified and `--precompile` is specified, we 
will generate the reduced BMI in GenerateModuleInterfaceAction as a by-product.
- When `-fgen-reduced-bmi` is specified for a non-module unit. We don't do 
anything nor try to give a warn. This is more user friendly so that the end 
users can try to test and experiment with the feature without asking help from 
the build systems.

The core design idea is that users should be able to enable this easily with 
the existing cmake mechanisms.

The future plan for the flag is:
- Add this to clang19 and make it opt-in for 1~2 releases. It depends on the 
testing feedback to decide how long we like to make it opt-in.
- Then we can announce the existing BMI generating may be deprecated and 
suggesting people (end users or build systems) to enable this for 1~2 releases.
- Finally we will enable this by default. When that time comes, the term `BMI` 
will refer to the reduced BMI today and the existing BMI will only be 
meaningful to build systems which loves to support two phase compilations.

I'll send release notes and document  in seperate commits after this get landed.

>From 77c66427c279689256f007cc5706b5f74e47f9e6 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu 
Date: Tue, 12 Mar 2024 17:26:49 +0800
Subject: [PATCH] [C++20] [Modules] Introduce -fgen-reduced-bmi

---
 clang/include/clang/CodeGen/CodeGenAction.h   |  2 +
 clang/include/clang/Driver/Options.td |  6 +++
 .../include/clang/Frontend/FrontendOptions.h  |  9 +++-
 clang/include/clang/Serialization/ASTWriter.h |  7 +--
 clang/lib/CodeGen/CodeGenAction.cpp   | 19 +++
 clang/lib/Driver/Driver.cpp   | 27 +-
 clang/lib/Driver/ToolChains/Clang.cpp | 41 --
 clang/lib/Driver/ToolChains/Clang.h   | 14 +
 clang/lib/Frontend/FrontendActions.cpp|  7 +++
 clang/lib/Frontend/PrecompiledPreamble.cpp|  3 +-
 clang/lib/Serialization/GeneratePCH.cpp   | 23 ++--
 .../test/Driver/module-fgen-reduced-bmi.cppm  | 53 +++
 clang/test/Modules/gen-reduced-bmi.cppm   | 36 +
 13 files changed, 220 insertions(+), 27 deletions(-)
 create mode 100644 clang/test/Driver/module-fgen-reduced-bmi.cppm
 create mode 100644 clang/test/Modules/gen-reduced-bmi.cppm

diff --git a/clang/include/clang/CodeGen/CodeGenAction.h 
b/clang/include/clang/CodeGen/CodeGenAction.h
index 7ad2988e589eb2..186dbb43f01ef7 100644
--- a/clang/include/clang/CodeGen/CodeGenAction.h
+++ b/clang/include/clang/CodeGen/CodeGenAction.h
@@ -57,6 +57,8 @@ class CodeGenAction : public ASTFrontendAction {
   bool loadLinkModules(CompilerInstance );
 
 protected:
+  bool BeginSourceFileAction(CompilerInstance ) override;
+
   /// Create a new code generation action.  If the optional \p _VMContext
   /// parameter is supplied, the action uses it without taking ownership,
   /// otherwise it creates a fresh LLVM context and takes ownership.
diff --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index aca8c9b0d5487a..b8ceeff9362df9 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -3018,6 +3018,7 @@ defm prebuilt_implicit_modules : 
BoolFOption<"prebuilt-implicit-modules",
 
 def fmodule_output_EQ : Joined<["-"], "fmodule-output=">,
   Flags<[NoXarchOption]>, Visibility<[ClangOption, CC1Option]>,
+  MarshallingInfoString>,
   HelpText<"Save intermediate module file results when compiling a standard 
C++ module unit.">;
 def fmodule_output : Flag<["-"], "fmodule-output">, Flags<[NoXarchOption]>,
   Visibility<[ClangOption, CC1Option]>,
@@ -3031,6 +3032,11 @@ defm skip_odr_check_in_gmf : BoolOption<"f", 
"skip-odr-check-in-gmf",
   "Perform ODR checks for decls in the global module fragment.">>,
   Group;
 
+def gen_reduced_bmi : Flag<["-"], "fgen-reduced-bmi">,
+  Group, Visibility<[ClangOption, CC1Option]>,
+  HelpText<"Generate the reduced BMI">,
+  MarshallingInfoFlag>;
+
 def fmodules_prune_interval : Joined<["-"], "fmodules-prune-interval=">, 
Group,
   Visibility<[ClangOption, CC1Option]>, MetaVarName<"">,
   HelpText<"Specify the interval (in seconds) between attempts to prune the 
module cache">,
diff --git a/clang/include/clang/Frontend/FrontendOptions.h 
b/clang/include/clang/Frontend/FrontendOptions.h
index 8085dbcbf671a6..ddfd4f30d1b773 100644
--- a/clang/include/clang/Frontend/FrontendOptions.h
+++ 

[clang] 4d62929 - [C++20] [Modules] Disambuguous Clang module and C++20 Named module further

2024-03-12 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2024-03-13T13:57:52+08:00
New Revision: 4d62929852849f768d7397f634cfdebc85de96a4

URL: 
https://github.com/llvm/llvm-project/commit/4d62929852849f768d7397f634cfdebc85de96a4
DIFF: 
https://github.com/llvm/llvm-project/commit/4d62929852849f768d7397f634cfdebc85de96a4.diff

LOG: [C++20] [Modules] Disambuguous Clang module and C++20 Named module further

This patch tries to make the boundary of clang module and C++20 named
module more clear.

The changes included:

- Rename `TranslationUnitKind::TU_Module` to
  `TranslationUnitKind::TU_ClangModule`.
- Rename `Sema::ActOnModuleInclude` to `Sema::ActOnAnnotModuleInclude`.
- Rename `ActOnModuleBegin` to `Sema::ActOnAnnotModuleBegin`.
- Rename `Sema::ActOnModuleEnd` to `Sema::ActOnAnnotModuleEnd`.
- Removes a warning if we're trying to compile a non-module unit as
  C++20 module unit. This is not actually useful and makes (the future)
  implementation unnecessarily complex.

This patch meant to be a NFC fix. But it shows that it fixed a bug
suprisingly that previously we would surppress the unused-value warning
in named modules. Because it shares the same logic with clang modules,
which has headers semantics. This shows the change is meaningful.

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Basic/LangOptions.h
clang/include/clang/Frontend/FrontendActions.h
clang/include/clang/Sema/Sema.h
clang/lib/Parse/Parser.cpp
clang/lib/Sema/Sema.cpp
clang/lib/Sema/SemaModule.cpp
clang/test/CXX/module/dcl.dcl/dcl.module/dcl.module.interface/p1.cppm
clang/test/Modules/pr72828.cppm

Removed: 
clang/test/Modules/missing-module-declaration.cppm



diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index c54105507753eb..d7ab1635cf12bc 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -11516,8 +11516,6 @@ def err_module_not_defined : Error<
 def err_module_redeclaration : Error<
   "translation unit contains multiple module declarations">;
 def note_prev_module_declaration : Note<"previous module declaration is here">;
-def err_module_declaration_missing : Error<
-  "missing 'export module' declaration in module interface unit">;
 def err_module_declaration_missing_after_global_module_introducer : Error<
   "missing 'module' declaration at end of global module fragment "
   "introduced here">;

diff  --git a/clang/include/clang/Basic/LangOptions.h 
b/clang/include/clang/Basic/LangOptions.h
index 862952d336ef31..08fc706e3cbf74 100644
--- a/clang/include/clang/Basic/LangOptions.h
+++ b/clang/include/clang/Basic/LangOptions.h
@@ -560,11 +560,6 @@ class LangOptions : public LangOptionsBase {
 return getCompilingModule() != CMK_None;
   }
 
-  /// Are we compiling a standard c++ module interface?
-  bool isCompilingModuleInterface() const {
-return getCompilingModule() == CMK_ModuleInterface;
-  }
-
   /// Are we compiling a module implementation?
   bool isCompilingModuleImplementation() const {
 return !isCompilingModule() && !ModuleName.empty();
@@ -993,8 +988,8 @@ enum TranslationUnitKind {
   /// not complete.
   TU_Prefix,
 
-  /// The translation unit is a module.
-  TU_Module,
+  /// The translation unit is a clang module.
+  TU_ClangModule,
 
   /// The translation unit is a is a complete translation unit that we might
   /// incrementally extend later.

diff  --git a/clang/include/clang/Frontend/FrontendActions.h 
b/clang/include/clang/Frontend/FrontendActions.h
index 8441af2ee3e718..a620ddfc40447d 100644
--- a/clang/include/clang/Frontend/FrontendActions.h
+++ b/clang/include/clang/Frontend/FrontendActions.h
@@ -125,7 +125,7 @@ class GenerateModuleAction : public ASTFrontendAction {
  StringRef InFile) override;
 
   TranslationUnitKind getTranslationUnitKind() override {
-return TU_Module;
+return TU_ClangModule;
   }
 
   bool hasASTFileSupport() const override { return false; }
@@ -138,7 +138,9 @@ class GenerateInterfaceStubsAction : public 
ASTFrontendAction {
   std::unique_ptr CreateASTConsumer(CompilerInstance ,
  StringRef InFile) override;
 
-  TranslationUnitKind getTranslationUnitKind() override { return TU_Module; }
+  TranslationUnitKind getTranslationUnitKind() override {
+return TU_ClangModule;
+  }
   bool hasASTFileSupport() const override { return false; }
 };
 
@@ -159,6 +161,8 @@ class GenerateModuleInterfaceAction : public 
GenerateModuleAction {
   std::unique_ptr CreateASTConsumer(CompilerInstance ,
  StringRef InFile) override;
 
+  TranslationUnitKind getTranslationUnitKind() override { return TU_Complete; }
+
   std::unique_ptr
   CreateOutputFile(CompilerInstance 

[clang] 5d7796e - [NFC] [C++20] [Modules] Refactor ReducedBMIGenerator

2024-03-12 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2024-03-13T11:22:32+08:00
New Revision: 5d7796e674224be54c48a8db981f4134845bcc7c

URL: 
https://github.com/llvm/llvm-project/commit/5d7796e674224be54c48a8db981f4134845bcc7c
DIFF: 
https://github.com/llvm/llvm-project/commit/5d7796e674224be54c48a8db981f4134845bcc7c.diff

LOG: [NFC] [C++20] [Modules] Refactor ReducedBMIGenerator

Changes:
- Don't lookup the emitting module from HeaderSearch. We will use the
  module from the ASTContext directly.
- Remove some useless arguments. Let's addback in the future if
  required.

Added: 


Modified: 
clang/include/clang/Serialization/ASTWriter.h
clang/lib/Frontend/FrontendActions.cpp
clang/lib/Serialization/GeneratePCH.cpp

Removed: 




diff  --git a/clang/include/clang/Serialization/ASTWriter.h 
b/clang/include/clang/Serialization/ASTWriter.h
index e5db486a71a490..3ed9803fa3745b 100644
--- a/clang/include/clang/Serialization/ASTWriter.h
+++ b/clang/include/clang/Serialization/ASTWriter.h
@@ -868,6 +868,8 @@ class PCHGenerator : public SemaConsumer {
 return SemaPtr->getDiagnostics();
   }
 
+  virtual Module *getEmittingModule(ASTContext );
+
 public:
   PCHGenerator(const Preprocessor , InMemoryModuleCache ,
StringRef OutputFile, StringRef isysroot,
@@ -887,10 +889,12 @@ class PCHGenerator : public SemaConsumer {
 };
 
 class ReducedBMIGenerator : public PCHGenerator {
+protected:
+  virtual Module *getEmittingModule(ASTContext ) override;
+
 public:
   ReducedBMIGenerator(const Preprocessor , InMemoryModuleCache ,
-  StringRef OutputFile, std::shared_ptr Buffer,
-  bool IncludeTimestamps);
+  StringRef OutputFile);
 
   void HandleTranslationUnit(ASTContext ) override;
 };

diff  --git a/clang/lib/Frontend/FrontendActions.cpp 
b/clang/lib/Frontend/FrontendActions.cpp
index 50338bfa670f83..81fcd8d5ae9bd3 100644
--- a/clang/lib/Frontend/FrontendActions.cpp
+++ b/clang/lib/Frontend/FrontendActions.cpp
@@ -293,11 +293,9 @@ 
GenerateModuleInterfaceAction::CreateOutputFile(CompilerInstance ,
 std::unique_ptr
 GenerateReducedModuleInterfaceAction::CreateASTConsumer(CompilerInstance ,
 StringRef InFile) {
-  auto Buffer = std::make_shared();
-  return std::make_unique(
-  CI.getPreprocessor(), CI.getModuleCache(),
-  CI.getFrontendOpts().OutputFile, Buffer,
-  /*IncludeTimestamps=*/+CI.getFrontendOpts().IncludeTimestamps);
+  return std::make_unique(CI.getPreprocessor(),
+   CI.getModuleCache(),
+   
CI.getFrontendOpts().OutputFile);
 }
 
 bool GenerateHeaderUnitAction::BeginSourceFileAction(CompilerInstance ) {

diff  --git a/clang/lib/Serialization/GeneratePCH.cpp 
b/clang/lib/Serialization/GeneratePCH.cpp
index 2b511b2d5a90a2..f54db36d4a0199 100644
--- a/clang/lib/Serialization/GeneratePCH.cpp
+++ b/clang/lib/Serialization/GeneratePCH.cpp
@@ -41,6 +41,21 @@ PCHGenerator::PCHGenerator(
 PCHGenerator::~PCHGenerator() {
 }
 
+Module *PCHGenerator::getEmittingModule(ASTContext &) {
+  Module *M = nullptr;
+
+  if (PP.getLangOpts().isCompilingModule()) {
+M = PP.getHeaderSearchInfo().lookupModule(PP.getLangOpts().CurrentModule,
+  SourceLocation(),
+  /*AllowSearch*/ false);
+if (!M)
+  assert(PP.getDiagnostics().hasErrorOccurred() &&
+ "emitting module but current module doesn't exist");
+  }
+
+  return M;
+}
+
 void PCHGenerator::HandleTranslationUnit(ASTContext ) {
   // Don't create a PCH if there were fatal failures during module loading.
   if (PP.getModuleLoader().HadFatalFailure)
@@ -50,16 +65,7 @@ void PCHGenerator::HandleTranslationUnit(ASTContext ) {
   if (hasErrors && !AllowASTWithErrors)
 return;
 
-  Module *Module = nullptr;
-  if (PP.getLangOpts().isCompilingModule()) {
-Module = PP.getHeaderSearchInfo().lookupModule(
-PP.getLangOpts().CurrentModule, SourceLocation(),
-/*AllowSearch*/ false);
-if (!Module) {
-  assert(hasErrors && "emitting module but current module doesn't exist");
-  return;
-}
-  }
+  Module *Module = getEmittingModule(Ctx);
 
   // Errors that do not prevent the PCH from being written should not cause the
   // overall compilation to fail either.
@@ -84,16 +90,22 @@ ASTDeserializationListener 
*PCHGenerator::GetASTDeserializationListener() {
 
 ReducedBMIGenerator::ReducedBMIGenerator(const Preprocessor ,
  InMemoryModuleCache ,
- StringRef OutputFile,
- std::shared_ptr Buffer,
- bool IncludeTimestamps)
+ StringRef OutputFile)
 : 

[clang] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use thread pool in P1689 per file mode (PR #84285)

2024-03-12 Thread Chuanqi Xu via cfe-commits

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


[clang] Reland "[clang][modules] Print library module manifest path." (PR #82160)

2024-03-12 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

I sent the new PR in https://github.com/llvm/llvm-project/pull/84881. See the 
comments there for details.

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


[clang] Reland Print library module manifest path again (PR #84881)

2024-03-12 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 created 
https://github.com/llvm/llvm-project/pull/84881

Following of https://github.com/llvm/llvm-project/pull/82160

The reason why the above PR fails is that the `--sysroot` has lower priority 
than the libc++ built from the same source. On the one hand, it matches the 
codes behavior. We will add the built libc++ project paths in the ToolChain 
class. But we will only add the path related to sysroot in Linux class, which 
is derived from the ToolChain classes. So the paths of just built libc++ is in 
the front of the paths relative to sysroot. On the other hand, the behavior 
should be good from the higher level.  Since the just built libc++ has the same 
version number with the just built clang, so it makes sense that these 2 
compilers just matches.

So for patch it self, I hacked it by using resource dir in the test since the 
resource dir has the higher priority, which is not strongly correct since we 
won't do that in practice.

@kaz7 would you like to test on your environment to avoid this get reverted 
again?

On the libc++ side, it shows that it lacks a `modules.json` file for the just 
built libc++ directory. If we don't have that, it will be problematic to use 
std modules from the just built clang and libc++ pair. Then it is not good. And 
I feel it may be problematic for future compiler/standard library developers. 
So I feel this is somewhat  a libc++ issue that need to be fixed.

Also if we don't like the hacked test in the current patch, we must wait for 
libc++ to fix this to proceed. But I feel this is somewhat odd since the test 
of clang shouldn't dependent on libc++.

CC: @mordante 

>From 27665923ce0b9974601d7e5880506e3560bade19 Mon Sep 17 00:00:00 2001
From: Mark de Wever 
Date: Sun, 3 Mar 2024 17:58:08 +0100
Subject: [PATCH 1/2] Reland "[clang][modules] Print library module manifest
 path." (#82160)

This implements a way for the compiler to find the modules.json
associated with the C++23 Standard library modules.

This is based on a discussion in SG15. At the moment no Standard library
installs this manifest. #75741 adds this feature in libc++.

This reverts commit 82f424f766be00b037a706a835d0a0663a2680f1.

Disables the tests on non-X86 platforms as suggested.
---
 clang/include/clang/Driver/Driver.h   | 10 +
 clang/include/clang/Driver/Options.td |  3 ++
 clang/lib/Driver/Driver.cpp   | 44 +++
 ...les-print-library-module-manifest-path.cpp | 40 +
 4 files changed, 97 insertions(+)
 create mode 100644 
clang/test/Driver/modules-print-library-module-manifest-path.cpp

diff --git a/clang/include/clang/Driver/Driver.h 
b/clang/include/clang/Driver/Driver.h
index c4cab360bab3bb..bcf8c1295f2ddf 100644
--- a/clang/include/clang/Driver/Driver.h
+++ b/clang/include/clang/Driver/Driver.h
@@ -615,6 +615,16 @@ class Driver {
   // FIXME: This should be in CompilationInfo.
   std::string GetProgramPath(StringRef Name, const ToolChain ) const;
 
+  /// Lookup the path to the Standard library module manifest.
+  ///
+  /// \param C - The compilation.
+  /// \param TC - The tool chain for additional information on
+  /// directories to search.
+  //
+  // FIXME: This should be in CompilationInfo.
+  std::string GetStdModuleManifestPath(const Compilation ,
+   const ToolChain ) const;
+
   /// HandleAutocompletions - Handle --autocomplete by searching and printing
   /// possible flags, descriptions, and its arguments.
   void HandleAutocompletions(StringRef PassedFlags) const;
diff --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index aca8c9b0d5487a..6e7f142789c994 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5374,6 +5374,9 @@ def print_resource_dir : Flag<["-", "--"], 
"print-resource-dir">,
 def print_search_dirs : Flag<["-", "--"], "print-search-dirs">,
   HelpText<"Print the paths used for finding libraries and programs">,
   Visibility<[ClangOption, CLOption]>;
+def print_std_module_manifest_path : Flag<["-", "--"], 
"print-library-module-manifest-path">,
+  HelpText<"Print the path for the C++ Standard library module manifest">,
+  Visibility<[ClangOption, CLOption]>;
 def print_targets : Flag<["-", "--"], "print-targets">,
   HelpText<"Print the registered targets">,
   Visibility<[ClangOption, CLOption]>;
diff --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 190782a79a2456..eae27769b73ec0 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -2196,6 +2196,12 @@ bool Driver::HandleImmediateArgs(const Compilation ) {
 return false;
   }
 
+  if (C.getArgs().hasArg(options::OPT_print_std_module_manifest_path)) {
+llvm::outs() << GetStdModuleManifestPath(C, C.getDefaultToolChain())
+ << '\n';
+return false;
+  }
+
   if (C.getArgs().hasArg(options::OPT_print_runtime_dir)) {
 if 

[clang] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use thread pool in P1689 per file mode (PR #84285)

2024-03-11 Thread Chuanqi Xu via cfe-commits


@@ -893,102 +889,118 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
   if (Format == ScanningOutputFormat::Full)
 FD.emplace(ModuleName.empty() ? Inputs.size() : 0);
 
-  if (Verbose) {
-llvm::outs() << "Running clang-scan-deps on " << Inputs.size()
- << " files using " << Pool.getMaxConcurrency() << " 
workers\n";
-  }
-
-  llvm::Timer T;
-  T.startTimer();
-
-  for (unsigned I = 0; I < Pool.getMaxConcurrency(); ++I) {
-Pool.async([&, I]() {
-  llvm::DenseSet AlreadySeenModules;
-  while (auto MaybeInputIndex = GetNextInputIndex()) {
-size_t LocalIndex = *MaybeInputIndex;
-const tooling::CompileCommand *Input = [LocalIndex];
-std::string Filename = std::move(Input->Filename);
-std::string CWD = std::move(Input->Directory);
-
-std::optional MaybeModuleName;
-if (!ModuleName.empty())
-  MaybeModuleName = ModuleName;
-
-std::string OutputDir(ModuleFilesDir);
-if (OutputDir.empty())
-  OutputDir = getModuleCachePath(Input->CommandLine);
-auto LookupOutput = [&](const ModuleID , ModuleOutputKind MOK) {
-  return ::lookupModuleOutput(MID, MOK, OutputDir);
-};
-
-// Run the tool on it.
-if (Format == ScanningOutputFormat::Make) {
-  auto MaybeFile =
-  WorkerTools[I]->getDependencyFile(Input->CommandLine, CWD);
-  if (handleMakeDependencyToolResult(Filename, MaybeFile, DependencyOS,
- Errs))
-HadErrors = true;
-} else if (Format == ScanningOutputFormat::P1689) {
-  // It is useful to generate the make-format dependency output during
-  // the scanning for P1689. Otherwise the users need to scan again for
-  // it. We will generate the make-format dependency output if we find
-  // `-MF` in the command lines.
-  std::string MakeformatOutputPath;
-  std::string MakeformatOutput;
-
-  auto MaybeRule = WorkerTools[I]->getP1689ModuleDependencyFile(
-  *Input, CWD, MakeformatOutput, MakeformatOutputPath);
-
-  if (handleP1689DependencyToolResult(Filename, MaybeRule, PD, Errs))
-HadErrors = true;
+  std::vector> WorkerTools;

ChuanqiXu9 wrote:

Nice catch. Done.

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


[clang] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use thread pool in P1689 per file mode (PR #84285)

2024-03-11 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 updated 
https://github.com/llvm/llvm-project/pull/84285

>From 48b3261e1d217b7ce78180314a222dca4d6aba18 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu 
Date: Thu, 7 Mar 2024 15:19:28 +0800
Subject: [PATCH 1/5] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use
 thread pool in P1689 per file mode

I suddenly found that the clang scan deps may use all concurrent threads
to scan the files. It makes sense in the batch mode. But in P1689
per file mode, it simply wastes times.
---
 clang/tools/clang-scan-deps/ClangScanDeps.cpp | 204 +-
 1 file changed, 108 insertions(+), 96 deletions(-)

diff --git a/clang/tools/clang-scan-deps/ClangScanDeps.cpp 
b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
index d042fecc3dbe63..843816a8ed6515 100644
--- a/clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -744,6 +744,9 @@ getCompilationDataBase(int argc, char **argv, std::string 
) {
 return nullptr;
   }
 
+  // Only 1 threads is required if P1689 per file mode.
+  NumThreads = 1;
+
   // There might be multiple jobs for a compilation. Extract the specified
   // output filename from the last job.
   auto LastCmd = C->getJobs().end();
@@ -867,13 +870,6 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
   // Print out the dependency results to STDOUT by default.
   SharedStream DependencyOS(llvm::outs());
 
-  DependencyScanningService Service(ScanMode, Format, OptimizeArgs,
-EagerLoadModules);
-  llvm::DefaultThreadPool Pool(llvm::hardware_concurrency(NumThreads));
-  std::vector> WorkerTools;
-  for (unsigned I = 0; I < Pool.getMaxConcurrency(); ++I)
-WorkerTools.push_back(std::make_unique(Service));
-
   std::vector Inputs =
   AdjustingCompilations->getAllCompileCommands();
 
@@ -893,102 +889,118 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
   if (Format == ScanningOutputFormat::Full)
 FD.emplace(ModuleName.empty() ? Inputs.size() : 0);
 
-  if (Verbose) {
-llvm::outs() << "Running clang-scan-deps on " << Inputs.size()
- << " files using " << Pool.getMaxConcurrency() << " 
workers\n";
-  }
-
-  llvm::Timer T;
-  T.startTimer();
-
-  for (unsigned I = 0; I < Pool.getMaxConcurrency(); ++I) {
-Pool.async([&, I]() {
-  llvm::DenseSet AlreadySeenModules;
-  while (auto MaybeInputIndex = GetNextInputIndex()) {
-size_t LocalIndex = *MaybeInputIndex;
-const tooling::CompileCommand *Input = [LocalIndex];
-std::string Filename = std::move(Input->Filename);
-std::string CWD = std::move(Input->Directory);
-
-std::optional MaybeModuleName;
-if (!ModuleName.empty())
-  MaybeModuleName = ModuleName;
-
-std::string OutputDir(ModuleFilesDir);
-if (OutputDir.empty())
-  OutputDir = getModuleCachePath(Input->CommandLine);
-auto LookupOutput = [&](const ModuleID , ModuleOutputKind MOK) {
-  return ::lookupModuleOutput(MID, MOK, OutputDir);
-};
-
-// Run the tool on it.
-if (Format == ScanningOutputFormat::Make) {
-  auto MaybeFile =
-  WorkerTools[I]->getDependencyFile(Input->CommandLine, CWD);
-  if (handleMakeDependencyToolResult(Filename, MaybeFile, DependencyOS,
- Errs))
-HadErrors = true;
-} else if (Format == ScanningOutputFormat::P1689) {
-  // It is useful to generate the make-format dependency output during
-  // the scanning for P1689. Otherwise the users need to scan again for
-  // it. We will generate the make-format dependency output if we find
-  // `-MF` in the command lines.
-  std::string MakeformatOutputPath;
-  std::string MakeformatOutput;
-
-  auto MaybeRule = WorkerTools[I]->getP1689ModuleDependencyFile(
-  *Input, CWD, MakeformatOutput, MakeformatOutputPath);
-
-  if (handleP1689DependencyToolResult(Filename, MaybeRule, PD, Errs))
-HadErrors = true;
+  std::vector> WorkerTools;
 
-  if (!MakeformatOutputPath.empty() && !MakeformatOutput.empty() &&
-  !HadErrors) {
-static std::mutex Lock;
-// With compilation database, we may open different files
-// concurrently or we may write the same file concurrently. So we
-// use a map here to allow multiple compile commands to write to 
the
-// same file. Also we need a lock here to avoid data race.
-static llvm::StringMap OSs;
-std::unique_lock LockGuard(Lock);
-
-auto OSIter = OSs.find(MakeformatOutputPath);
-if (OSIter == OSs.end()) {
-  std::error_code EC;
-  OSIter = OSs.try_emplace(MakeformatOutputPath,
-   MakeformatOutputPath, EC)
- 

[clang] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use thread pool in P1689 per file mode (PR #84285)

2024-03-11 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 updated 
https://github.com/llvm/llvm-project/pull/84285

>From 48b3261e1d217b7ce78180314a222dca4d6aba18 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu 
Date: Thu, 7 Mar 2024 15:19:28 +0800
Subject: [PATCH 1/4] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use
 thread pool in P1689 per file mode

I suddenly found that the clang scan deps may use all concurrent threads
to scan the files. It makes sense in the batch mode. But in P1689
per file mode, it simply wastes times.
---
 clang/tools/clang-scan-deps/ClangScanDeps.cpp | 204 +-
 1 file changed, 108 insertions(+), 96 deletions(-)

diff --git a/clang/tools/clang-scan-deps/ClangScanDeps.cpp 
b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
index d042fecc3dbe63..843816a8ed6515 100644
--- a/clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -744,6 +744,9 @@ getCompilationDataBase(int argc, char **argv, std::string 
) {
 return nullptr;
   }
 
+  // Only 1 threads is required if P1689 per file mode.
+  NumThreads = 1;
+
   // There might be multiple jobs for a compilation. Extract the specified
   // output filename from the last job.
   auto LastCmd = C->getJobs().end();
@@ -867,13 +870,6 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
   // Print out the dependency results to STDOUT by default.
   SharedStream DependencyOS(llvm::outs());
 
-  DependencyScanningService Service(ScanMode, Format, OptimizeArgs,
-EagerLoadModules);
-  llvm::DefaultThreadPool Pool(llvm::hardware_concurrency(NumThreads));
-  std::vector> WorkerTools;
-  for (unsigned I = 0; I < Pool.getMaxConcurrency(); ++I)
-WorkerTools.push_back(std::make_unique(Service));
-
   std::vector Inputs =
   AdjustingCompilations->getAllCompileCommands();
 
@@ -893,102 +889,118 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
   if (Format == ScanningOutputFormat::Full)
 FD.emplace(ModuleName.empty() ? Inputs.size() : 0);
 
-  if (Verbose) {
-llvm::outs() << "Running clang-scan-deps on " << Inputs.size()
- << " files using " << Pool.getMaxConcurrency() << " 
workers\n";
-  }
-
-  llvm::Timer T;
-  T.startTimer();
-
-  for (unsigned I = 0; I < Pool.getMaxConcurrency(); ++I) {
-Pool.async([&, I]() {
-  llvm::DenseSet AlreadySeenModules;
-  while (auto MaybeInputIndex = GetNextInputIndex()) {
-size_t LocalIndex = *MaybeInputIndex;
-const tooling::CompileCommand *Input = [LocalIndex];
-std::string Filename = std::move(Input->Filename);
-std::string CWD = std::move(Input->Directory);
-
-std::optional MaybeModuleName;
-if (!ModuleName.empty())
-  MaybeModuleName = ModuleName;
-
-std::string OutputDir(ModuleFilesDir);
-if (OutputDir.empty())
-  OutputDir = getModuleCachePath(Input->CommandLine);
-auto LookupOutput = [&](const ModuleID , ModuleOutputKind MOK) {
-  return ::lookupModuleOutput(MID, MOK, OutputDir);
-};
-
-// Run the tool on it.
-if (Format == ScanningOutputFormat::Make) {
-  auto MaybeFile =
-  WorkerTools[I]->getDependencyFile(Input->CommandLine, CWD);
-  if (handleMakeDependencyToolResult(Filename, MaybeFile, DependencyOS,
- Errs))
-HadErrors = true;
-} else if (Format == ScanningOutputFormat::P1689) {
-  // It is useful to generate the make-format dependency output during
-  // the scanning for P1689. Otherwise the users need to scan again for
-  // it. We will generate the make-format dependency output if we find
-  // `-MF` in the command lines.
-  std::string MakeformatOutputPath;
-  std::string MakeformatOutput;
-
-  auto MaybeRule = WorkerTools[I]->getP1689ModuleDependencyFile(
-  *Input, CWD, MakeformatOutput, MakeformatOutputPath);
-
-  if (handleP1689DependencyToolResult(Filename, MaybeRule, PD, Errs))
-HadErrors = true;
+  std::vector> WorkerTools;
 
-  if (!MakeformatOutputPath.empty() && !MakeformatOutput.empty() &&
-  !HadErrors) {
-static std::mutex Lock;
-// With compilation database, we may open different files
-// concurrently or we may write the same file concurrently. So we
-// use a map here to allow multiple compile commands to write to 
the
-// same file. Also we need a lock here to avoid data race.
-static llvm::StringMap OSs;
-std::unique_lock LockGuard(Lock);
-
-auto OSIter = OSs.find(MakeformatOutputPath);
-if (OSIter == OSs.end()) {
-  std::error_code EC;
-  OSIter = OSs.try_emplace(MakeformatOutputPath,
-   MakeformatOutputPath, EC)
- 

[clang] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use thread pool in P1689 per file mode (PR #84285)

2024-03-11 Thread Chuanqi Xu via cfe-commits


@@ -744,6 +744,9 @@ getCompilationDataBase(int argc, char **argv, std::string 
) {
 return nullptr;
   }
 
+  // Only 1 threads is required if P1689 per file mode.
+  NumThreads = 1;

ChuanqiXu9 wrote:

Oh, sorry. I don't know why I missed this somehow. This should be done now.

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


[clang] [C++20] [Modules] Introduce a tool 'clang-named-modules-querier' and two plugins 'ClangGetUsedFilesFromModulesPlugin' and 'ClangGetDeclsInModulesPlugin' (PR #72956)

2024-03-11 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

> > ClangGetUsedFilesFromModulesPlugin
> 
> This has a hole where if a currently-unused file is not listed, but it is 
> changed in such a way that it now matters (e.g., it changes include order, 
> adds/removes includes, etc.), we need to recompile consumers.
> 
> > what happens if someone adds an overload, or other interesting name 
> > resolution to the module?
> 
> We would need to do (at least) one of:
> 
> * track considered-but-discarded decls (e.g., if something SFINAE'd away now 
> matters because of a new decl);
> * track "new" decls since the last compile (not sure how the state tracking 
> works here though) and recompile if any show up
> 
> > ```
> >  "col": 12,
> >  "kind": "Function",
> >  "line": 3,
> > ```
> 
> So we change the decl hash if a comment adds a line? That seems like 
> low-hanging fruit to me. Can we enumerate decls and use an index instead? 
> That depends on preprocessor state though, so may be hard to externally 
> verify…

Why I chose to use the location is that in the discourse discussion, it shows 
the location is still meaningful in debug information in generated objects. And 
for index..., I feel it is hard to tell the meaning of the index outside the 
compiler. As you said, how can a consumer be sure that 2 decls with the same 
index in 2 different invocations to be the same one...

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


[clang] Reland "[clang][modules] Print library module manifest path." (PR #82160)

2024-03-11 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

> @ChuanqiXu9 since you suggested this test approach

It looks like that I failed to understand VE is under X86 also...

> do you know whether this is the expected behavior of -sysroot ?

I am not sure. This is surprising to me too.



> The point is to build libraries and test clang at once. The `TC.getFilePaths` 
> is constructed from following items in `ToolChain::ToolChain`
> 
> 1. `BUILD/bin/../lib/x86_64-unknown-linux-gnu`
> 2. `%t/Inputs/usr/lib/x86_64-linux-gnu`
> 3. `%t/Inputs/usr/lib`
> 
> Yes. It contains 1st item at run time if you build libraries. As a result, 
> `GetStdModuleManifestPath` find 
> `BUILD/bin/../lib/x86_64-unknown-linux-gnu/libc++.so` first. However, 
> `modules.json` is at `%t/Inputs/usr/lib/x86_64-linux-gnu/modules.json`.
> 
> Hope this helps you.

It looks like this is not special to VE but reproducible for every constructing 
the clang and libc++ at once. So  I'll try to look at it if I can reproduce it 
locally.

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


[clang] 0f501c3 - Revert "[C++20][Coroutines] Lambda-coroutine with operator new in promise_type (#84193)"

2024-03-11 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2024-03-11T17:02:43+08:00
New Revision: 0f501c30b9601627c236f9abca8a3befba5dc161

URL: 
https://github.com/llvm/llvm-project/commit/0f501c30b9601627c236f9abca8a3befba5dc161
DIFF: 
https://github.com/llvm/llvm-project/commit/0f501c30b9601627c236f9abca8a3befba5dc161.diff

LOG: Revert "[C++20][Coroutines] Lambda-coroutine with operator new in 
promise_type (#84193)"

This reverts commit 35d3b33ba5c9b90443ac985f2521b78f84b611fe.

See the comments in https://github.com/llvm/llvm-project/pull/84193 for
details

Added: 


Modified: 
clang/include/clang/Sema/Sema.h
clang/lib/Sema/SemaCoroutine.cpp
clang/lib/Sema/SemaExprCXX.cpp

Removed: 
clang/test/SemaCXX/gh84064-1.cpp
clang/test/SemaCXX/gh84064-2.cpp



diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 00b3f53f5c1c66..267c79cc057cba 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -6752,18 +6752,10 @@ class Sema final {
 SourceLocation RParenLoc);
 
    ActOnCXXThis -  Parse 'this' pointer.
-  ///
-  /// \param ThisRefersToClosureObject Whether to skip the 'this' check for a
-  /// lambda because 'this' refers to the closure object.
-  ExprResult ActOnCXXThis(SourceLocation loc,
-  bool ThisRefersToClosureObject = false);
+  ExprResult ActOnCXXThis(SourceLocation loc);
 
   /// Build a CXXThisExpr and mark it referenced in the current context.
-  ///
-  /// \param ThisRefersToClosureObject Whether to skip the 'this' check for a
-  /// lambda because 'this' refers to the closure object.
-  Expr *BuildCXXThisExpr(SourceLocation Loc, QualType Type, bool IsImplicit,
- bool ThisRefersToClosureObject = false);
+  Expr *BuildCXXThisExpr(SourceLocation Loc, QualType Type, bool IsImplicit);
   void MarkThisReferenced(CXXThisExpr *This);
 
   /// Try to retrieve the type of the 'this' pointer.

diff  --git a/clang/lib/Sema/SemaCoroutine.cpp 
b/clang/lib/Sema/SemaCoroutine.cpp
index 5206fc7621c7cd..736632857efc36 100644
--- a/clang/lib/Sema/SemaCoroutine.cpp
+++ b/clang/lib/Sema/SemaCoroutine.cpp
@@ -25,7 +25,6 @@
 #include "clang/Sema/Initialization.h"
 #include "clang/Sema/Overload.h"
 #include "clang/Sema/ScopeInfo.h"
-#include "clang/Sema/Sema.h"
 #include "clang/Sema/SemaInternal.h"
 #include "llvm/ADT/SmallSet.h"
 
@@ -1291,21 +1290,8 @@ bool CoroutineStmtBuilder::makeReturnOnAllocFailure() {
 static bool collectPlacementArgs(Sema , FunctionDecl , SourceLocation Loc,
  SmallVectorImpl ) {
   if (auto *MD = dyn_cast()) {
-if (MD->isImplicitObjectMemberFunction()) {
-  ExprResult ThisExpr{};
-
-  if (isLambdaCallOperator(MD) && !MD->isStatic()) {
-Qualifiers ThisQuals = MD->getMethodQualifiers();
-CXXRecordDecl *Record = MD->getParent();
-
-Sema::CXXThisScopeRAII ThisScope(S, Record, ThisQuals,
- Record != nullptr);
-
-ThisExpr = S.ActOnCXXThis(Loc, /*ThisRefersToClosureObject=*/true);
-  } else {
-ThisExpr = S.ActOnCXXThis(Loc);
-  }
-
+if (MD->isImplicitObjectMemberFunction() && !isLambdaCallOperator(MD)) {
+  ExprResult ThisExpr = S.ActOnCXXThis(Loc);
   if (ThisExpr.isInvalid())
 return false;
   ThisExpr = S.CreateBuiltinUnaryOp(Loc, UO_Deref, ThisExpr.get());

diff  --git a/clang/lib/Sema/SemaExprCXX.cpp b/clang/lib/Sema/SemaExprCXX.cpp
index 88e3d9ced044cb..c34a40fa7c81ac 100644
--- a/clang/lib/Sema/SemaExprCXX.cpp
+++ b/clang/lib/Sema/SemaExprCXX.cpp
@@ -1414,8 +1414,7 @@ bool Sema::CheckCXXThisCapture(SourceLocation Loc, const 
bool Explicit,
   return false;
 }
 
-ExprResult Sema::ActOnCXXThis(SourceLocation Loc,
-  bool ThisRefersToClosureObject) {
+ExprResult Sema::ActOnCXXThis(SourceLocation Loc) {
   /// C++ 9.3.2: In the body of a non-static member function, the keyword this
   /// is a non-lvalue expression whose value is the address of the object for
   /// which the function is called.
@@ -1435,18 +1434,13 @@ ExprResult Sema::ActOnCXXThis(SourceLocation Loc,
 return Diag(Loc, diag::err_invalid_this_use) << 0;
   }
 
-  return BuildCXXThisExpr(Loc, ThisTy, /*IsImplicit=*/false,
-  ThisRefersToClosureObject);
+  return BuildCXXThisExpr(Loc, ThisTy, /*IsImplicit=*/false);
 }
 
-Expr *Sema::BuildCXXThisExpr(SourceLocation Loc, QualType Type, bool 
IsImplicit,
- bool ThisRefersToClosureObject) {
+Expr *Sema::BuildCXXThisExpr(SourceLocation Loc, QualType Type,
+ bool IsImplicit) {
   auto *This = CXXThisExpr::Create(Context, Loc, Type, IsImplicit);
-
-  if (!ThisRefersToClosureObject) {
-MarkThisReferenced(This);
-  }
-
+  MarkThisReferenced(This);
   return This;
 }
 

diff  --git 

[clang] [C++20][Coroutines] Lambda-coroutine with operator new in promise_type (PR #84193)

2024-03-11 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

This commit breaks our coroutines library async_simple 
`https://github.com/alibaba/async_simple` and here is a (relative) minimal 
reproducer: https://godbolt.org/z/sG5jzcGEz

The reproducer comes from an implementation for async_simple::Generator 
(https://github.com/alibaba/async_simple/blob/main/async_simple/coro/Generator.h),
 which is basically the same implementation from the paper of `std::generator` 
in c++23. So possibly this may make that crash too. 

I'll revert this patch to avoid the regression now. Sorry for not testing it 
sufficiently.

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


[clang] 3f6bc1a - [C++20] [Moduls] Avoid computing odr hash for functions from comparing constraint expression

2024-03-10 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2024-03-11T11:39:21+08:00
New Revision: 3f6bc1adf805681293c2ef0b93b708ff52244c00

URL: 
https://github.com/llvm/llvm-project/commit/3f6bc1adf805681293c2ef0b93b708ff52244c00
DIFF: 
https://github.com/llvm/llvm-project/commit/3f6bc1adf805681293c2ef0b93b708ff52244c00.diff

LOG: [C++20] [Moduls] Avoid computing odr hash for functions from comparing 
constraint expression

Previously we disabled to compute ODR hash for declarations from the
global module fragment. However, we missed the case that the functions
lives in the concept requiments (see the attached the test files for
example). And the mismatch causes the potential crashment.

Due to we will set the function body as lazy after we deserialize it and
we will only take its body when needed. However, we don't allow to take
the body during deserializing. So it is actually potentially problematic
if we set the body as lazy first and computing the hash value of the
function, which requires to deserialize its body. So we will meet a
crash here.

This patch tries to solve the issue by not taking the body of the
function from GMF. Note that we can't skip comparing the constraint
expression from the GMF directly since it is an key part of the
function selecting and it may be the reason why we can't return 0
directly for `FunctionDecl::getODRHash()` from the GMF.

Added: 
clang/test/Modules/hashing-decls-in-exprs-from-gmf.cppm

Modified: 
clang/include/clang/AST/DeclBase.h
clang/include/clang/Serialization/ASTReader.h
clang/lib/AST/Decl.cpp
clang/lib/AST/DeclBase.cpp
clang/lib/Serialization/ASTReader.cpp
clang/lib/Serialization/ASTReaderDecl.cpp
clang/lib/Serialization/ASTWriter.cpp
clang/lib/Serialization/ASTWriterDecl.cpp

Removed: 




diff  --git a/clang/include/clang/AST/DeclBase.h 
b/clang/include/clang/AST/DeclBase.h
index 76810a86a78a46..47ed6d0d1db0df 100644
--- a/clang/include/clang/AST/DeclBase.h
+++ b/clang/include/clang/AST/DeclBase.h
@@ -673,6 +673,16 @@ class alignas(8) Decl {
   /// fragment. See [module.global.frag]p3,4 for details.
   bool isDiscardedInGlobalModuleFragment() const { return false; }
 
+  /// Check if we should skip checking ODRHash for declaration \param D.
+  ///
+  /// The existing ODRHash mechanism seems to be not stable enough and
+  /// the false positive ODR violation reports are annoying and we rarely see
+  /// true ODR violation reports. Also we learned that MSVC disabled ODR checks
+  /// for declarations in GMF. So we try to disable ODR checks in the GMF to
+  /// get better user experiences before we make the ODR violation checks 
stable
+  /// enough.
+  bool shouldSkipCheckingODR() const;
+
   /// Return true if this declaration has an attribute which acts as
   /// definition of the entity, such as 'alias' or 'ifunc'.
   bool hasDefiningAttr() const;

diff  --git a/clang/include/clang/Serialization/ASTReader.h 
b/clang/include/clang/Serialization/ASTReader.h
index 2002bf23c9595f..370d8037a4da17 100644
--- a/clang/include/clang/Serialization/ASTReader.h
+++ b/clang/include/clang/Serialization/ASTReader.h
@@ -2456,13 +2456,6 @@ class BitsUnpacker {
   uint32_t Value;
   uint32_t CurrentBitsIndex = ~0;
 };
-
-inline bool shouldSkipCheckingODR(const Decl *D) {
-  return D->getOwningModule() &&
- D->getASTContext().getLangOpts().SkipODRCheckInGMF &&
- D->getOwningModule()->isExplicitGlobalModule();
-}
-
 } // namespace clang
 
 #endif // LLVM_CLANG_SERIALIZATION_ASTREADER_H

diff  --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index d681791d3920c3..8626f04012f7d4 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -4496,7 +4496,7 @@ unsigned FunctionDecl::getODRHash() {
   }
 
   class ODRHash Hash;
-  Hash.AddFunctionDecl(this);
+  Hash.AddFunctionDecl(this, /*SkipBody=*/shouldSkipCheckingODR());
   setHasODRHash(true);
   ODRHash = Hash.CalculateHash();
   return ODRHash;

diff  --git a/clang/lib/AST/DeclBase.cpp b/clang/lib/AST/DeclBase.cpp
index fcedb3cfd176a0..04bbc49ab2f319 100644
--- a/clang/lib/AST/DeclBase.cpp
+++ b/clang/lib/AST/DeclBase.cpp
@@ -1102,6 +1102,11 @@ bool Decl::isInAnotherModuleUnit() const {
   return M != getASTContext().getCurrentNamedModule();
 }
 
+bool Decl::shouldSkipCheckingODR() const {
+  return getASTContext().getLangOpts().SkipODRCheckInGMF && getOwningModule() 
&&
+ getOwningModule()->isExplicitGlobalModule();
+}
+
 static Decl::Kind getKind(const Decl *D) { return D->getKind(); }
 static Decl::Kind getKind(const DeclContext *DC) { return DC->getDeclKind(); }
 

diff  --git a/clang/lib/Serialization/ASTReader.cpp 
b/clang/lib/Serialization/ASTReader.cpp
index 683a076e6bc399..ede9f6e93469b7 100644
--- a/clang/lib/Serialization/ASTReader.cpp
+++ b/clang/lib/Serialization/ASTReader.cpp
@@ -9762,7 +9762,7 @@ void ASTReader::finishPendingActions() {
 

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

2024-03-10 Thread Chuanqi Xu via cfe-commits

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

2024-03-10 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

I'll merge this since I find you may not have commit access.

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][Coroutines] lambda-coroutine with promise_type ctor. (PR #84519)

2024-03-10 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 approved this pull request.

LGTM.

https://github.com/llvm/llvm-project/pull/84519
___
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)

2024-03-10 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 approved this pull request.

LGTM then. Thanks.

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] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use thread pool in P1689 per file mode (PR #84285)

2024-03-07 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 updated 
https://github.com/llvm/llvm-project/pull/84285

>From dd9711be2368a299b408d0ff06ec9c1c0540083b Mon Sep 17 00:00:00 2001
From: Chuanqi Xu 
Date: Thu, 7 Mar 2024 15:19:28 +0800
Subject: [PATCH 1/3] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use
 thread pool in P1689 per file mode

I suddenly found that the clang scan deps may use all concurrent threads
to scan the files. It makes sense in the batch mode. But in P1689
per file mode, it simply wastes times.
---
 clang/tools/clang-scan-deps/ClangScanDeps.cpp | 204 +-
 1 file changed, 108 insertions(+), 96 deletions(-)

diff --git a/clang/tools/clang-scan-deps/ClangScanDeps.cpp 
b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
index d042fecc3dbe63..843816a8ed6515 100644
--- a/clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -744,6 +744,9 @@ getCompilationDataBase(int argc, char **argv, std::string 
) {
 return nullptr;
   }
 
+  // Only 1 threads is required if P1689 per file mode.
+  NumThreads = 1;
+
   // There might be multiple jobs for a compilation. Extract the specified
   // output filename from the last job.
   auto LastCmd = C->getJobs().end();
@@ -867,13 +870,6 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
   // Print out the dependency results to STDOUT by default.
   SharedStream DependencyOS(llvm::outs());
 
-  DependencyScanningService Service(ScanMode, Format, OptimizeArgs,
-EagerLoadModules);
-  llvm::DefaultThreadPool Pool(llvm::hardware_concurrency(NumThreads));
-  std::vector> WorkerTools;
-  for (unsigned I = 0; I < Pool.getMaxConcurrency(); ++I)
-WorkerTools.push_back(std::make_unique(Service));
-
   std::vector Inputs =
   AdjustingCompilations->getAllCompileCommands();
 
@@ -893,102 +889,118 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
   if (Format == ScanningOutputFormat::Full)
 FD.emplace(ModuleName.empty() ? Inputs.size() : 0);
 
-  if (Verbose) {
-llvm::outs() << "Running clang-scan-deps on " << Inputs.size()
- << " files using " << Pool.getMaxConcurrency() << " 
workers\n";
-  }
-
-  llvm::Timer T;
-  T.startTimer();
-
-  for (unsigned I = 0; I < Pool.getMaxConcurrency(); ++I) {
-Pool.async([&, I]() {
-  llvm::DenseSet AlreadySeenModules;
-  while (auto MaybeInputIndex = GetNextInputIndex()) {
-size_t LocalIndex = *MaybeInputIndex;
-const tooling::CompileCommand *Input = [LocalIndex];
-std::string Filename = std::move(Input->Filename);
-std::string CWD = std::move(Input->Directory);
-
-std::optional MaybeModuleName;
-if (!ModuleName.empty())
-  MaybeModuleName = ModuleName;
-
-std::string OutputDir(ModuleFilesDir);
-if (OutputDir.empty())
-  OutputDir = getModuleCachePath(Input->CommandLine);
-auto LookupOutput = [&](const ModuleID , ModuleOutputKind MOK) {
-  return ::lookupModuleOutput(MID, MOK, OutputDir);
-};
-
-// Run the tool on it.
-if (Format == ScanningOutputFormat::Make) {
-  auto MaybeFile =
-  WorkerTools[I]->getDependencyFile(Input->CommandLine, CWD);
-  if (handleMakeDependencyToolResult(Filename, MaybeFile, DependencyOS,
- Errs))
-HadErrors = true;
-} else if (Format == ScanningOutputFormat::P1689) {
-  // It is useful to generate the make-format dependency output during
-  // the scanning for P1689. Otherwise the users need to scan again for
-  // it. We will generate the make-format dependency output if we find
-  // `-MF` in the command lines.
-  std::string MakeformatOutputPath;
-  std::string MakeformatOutput;
-
-  auto MaybeRule = WorkerTools[I]->getP1689ModuleDependencyFile(
-  *Input, CWD, MakeformatOutput, MakeformatOutputPath);
-
-  if (handleP1689DependencyToolResult(Filename, MaybeRule, PD, Errs))
-HadErrors = true;
+  std::vector> WorkerTools;
 
-  if (!MakeformatOutputPath.empty() && !MakeformatOutput.empty() &&
-  !HadErrors) {
-static std::mutex Lock;
-// With compilation database, we may open different files
-// concurrently or we may write the same file concurrently. So we
-// use a map here to allow multiple compile commands to write to 
the
-// same file. Also we need a lock here to avoid data race.
-static llvm::StringMap OSs;
-std::unique_lock LockGuard(Lock);
-
-auto OSIter = OSs.find(MakeformatOutputPath);
-if (OSIter == OSs.end()) {
-  std::error_code EC;
-  OSIter = OSs.try_emplace(MakeformatOutputPath,
-   MakeformatOutputPath, EC)
- 

[clang] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use thread pool in P1689 per file mode (PR #84285)

2024-03-07 Thread Chuanqi Xu via cfe-commits


@@ -893,102 +889,118 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
   if (Format == ScanningOutputFormat::Full)
 FD.emplace(ModuleName.empty() ? Inputs.size() : 0);
 
-  if (Verbose) {
-llvm::outs() << "Running clang-scan-deps on " << Inputs.size()
- << " files using " << Pool.getMaxConcurrency() << " 
workers\n";
-  }
-
-  llvm::Timer T;
-  T.startTimer();
-
-  for (unsigned I = 0; I < Pool.getMaxConcurrency(); ++I) {
-Pool.async([&, I]() {
-  llvm::DenseSet AlreadySeenModules;
-  while (auto MaybeInputIndex = GetNextInputIndex()) {
-size_t LocalIndex = *MaybeInputIndex;
-const tooling::CompileCommand *Input = [LocalIndex];
-std::string Filename = std::move(Input->Filename);
-std::string CWD = std::move(Input->Directory);
-
-std::optional MaybeModuleName;
-if (!ModuleName.empty())
-  MaybeModuleName = ModuleName;
-
-std::string OutputDir(ModuleFilesDir);
-if (OutputDir.empty())
-  OutputDir = getModuleCachePath(Input->CommandLine);
-auto LookupOutput = [&](const ModuleID , ModuleOutputKind MOK) {
-  return ::lookupModuleOutput(MID, MOK, OutputDir);
-};
-
-// Run the tool on it.
-if (Format == ScanningOutputFormat::Make) {
-  auto MaybeFile =
-  WorkerTools[I]->getDependencyFile(Input->CommandLine, CWD);
-  if (handleMakeDependencyToolResult(Filename, MaybeFile, DependencyOS,
- Errs))
-HadErrors = true;
-} else if (Format == ScanningOutputFormat::P1689) {
-  // It is useful to generate the make-format dependency output during
-  // the scanning for P1689. Otherwise the users need to scan again for
-  // it. We will generate the make-format dependency output if we find
-  // `-MF` in the command lines.
-  std::string MakeformatOutputPath;
-  std::string MakeformatOutput;
-
-  auto MaybeRule = WorkerTools[I]->getP1689ModuleDependencyFile(
-  *Input, CWD, MakeformatOutput, MakeformatOutputPath);
-
-  if (handleP1689DependencyToolResult(Filename, MaybeRule, PD, Errs))
-HadErrors = true;
+  std::vector> WorkerTools;

ChuanqiXu9 wrote:

Done by moving this into the `ThreadPool` only branch and get rid of 
`std::unique_ptr`. It looks like we can't remove the vector entirely. Since the 
parameter type of `ScanningTask` is `DependencyScanningTool &` instead of 
`const DependencyScanningTool &`, so we may face lifetime issues if we 
construct DependencyScanningTool in place.

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


[clang] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use thread pool in P1689 per file mode (PR #84285)

2024-03-07 Thread Chuanqi Xu via cfe-commits


@@ -893,102 +889,118 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
   if (Format == ScanningOutputFormat::Full)
 FD.emplace(ModuleName.empty() ? Inputs.size() : 0);
 
-  if (Verbose) {
-llvm::outs() << "Running clang-scan-deps on " << Inputs.size()
- << " files using " << Pool.getMaxConcurrency() << " 
workers\n";
-  }
-
-  llvm::Timer T;
-  T.startTimer();
-
-  for (unsigned I = 0; I < Pool.getMaxConcurrency(); ++I) {
-Pool.async([&, I]() {
-  llvm::DenseSet AlreadySeenModules;
-  while (auto MaybeInputIndex = GetNextInputIndex()) {
-size_t LocalIndex = *MaybeInputIndex;
-const tooling::CompileCommand *Input = [LocalIndex];
-std::string Filename = std::move(Input->Filename);
-std::string CWD = std::move(Input->Directory);
-
-std::optional MaybeModuleName;
-if (!ModuleName.empty())
-  MaybeModuleName = ModuleName;
-
-std::string OutputDir(ModuleFilesDir);
-if (OutputDir.empty())
-  OutputDir = getModuleCachePath(Input->CommandLine);
-auto LookupOutput = [&](const ModuleID , ModuleOutputKind MOK) {
-  return ::lookupModuleOutput(MID, MOK, OutputDir);
-};
-
-// Run the tool on it.
-if (Format == ScanningOutputFormat::Make) {
-  auto MaybeFile =
-  WorkerTools[I]->getDependencyFile(Input->CommandLine, CWD);
-  if (handleMakeDependencyToolResult(Filename, MaybeFile, DependencyOS,
- Errs))
-HadErrors = true;
-} else if (Format == ScanningOutputFormat::P1689) {
-  // It is useful to generate the make-format dependency output during
-  // the scanning for P1689. Otherwise the users need to scan again for
-  // it. We will generate the make-format dependency output if we find
-  // `-MF` in the command lines.
-  std::string MakeformatOutputPath;
-  std::string MakeformatOutput;
-
-  auto MaybeRule = WorkerTools[I]->getP1689ModuleDependencyFile(
-  *Input, CWD, MakeformatOutput, MakeformatOutputPath);
-
-  if (handleP1689DependencyToolResult(Filename, MaybeRule, PD, Errs))
-HadErrors = true;
+  std::vector> WorkerTools;
 
-  if (!MakeformatOutputPath.empty() && !MakeformatOutput.empty() &&
-  !HadErrors) {
-static std::mutex Lock;
-// With compilation database, we may open different files
-// concurrently or we may write the same file concurrently. So we
-// use a map here to allow multiple compile commands to write to 
the
-// same file. Also we need a lock here to avoid data race.
-static llvm::StringMap OSs;
-std::unique_lock LockGuard(Lock);
-
-auto OSIter = OSs.find(MakeformatOutputPath);
-if (OSIter == OSs.end()) {
-  std::error_code EC;
-  OSIter = OSs.try_emplace(MakeformatOutputPath,
-   MakeformatOutputPath, EC)
-   .first;
-  if (EC)
-llvm::errs()
-<< "Failed to open P1689 make format output file \""
-<< MakeformatOutputPath << "\" for " << EC.message()
-<< "\n";
-}
+  auto ScanningTask = [&](unsigned I) {

ChuanqiXu9 wrote:

Done. It looks indeed better.

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


[clang] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use thread pool in P1689 per file mode (PR #84285)

2024-03-07 Thread Chuanqi Xu via cfe-commits


@@ -744,6 +744,9 @@ getCompilationDataBase(int argc, char **argv, std::string 
) {
 return nullptr;
   }
 
+  // Only 1 threads is required if P1689 per file mode.
+  NumThreads = 1;

ChuanqiXu9 wrote:

Makes sense. Done.

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


[clang] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use thread pool in P1689 per file mode (PR #84285)

2024-03-07 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 updated 
https://github.com/llvm/llvm-project/pull/84285

>From dd9711be2368a299b408d0ff06ec9c1c0540083b Mon Sep 17 00:00:00 2001
From: Chuanqi Xu 
Date: Thu, 7 Mar 2024 15:19:28 +0800
Subject: [PATCH 1/2] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use
 thread pool in P1689 per file mode

I suddenly found that the clang scan deps may use all concurrent threads
to scan the files. It makes sense in the batch mode. But in P1689
per file mode, it simply wastes times.
---
 clang/tools/clang-scan-deps/ClangScanDeps.cpp | 204 +-
 1 file changed, 108 insertions(+), 96 deletions(-)

diff --git a/clang/tools/clang-scan-deps/ClangScanDeps.cpp 
b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
index d042fecc3dbe63..843816a8ed6515 100644
--- a/clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -744,6 +744,9 @@ getCompilationDataBase(int argc, char **argv, std::string 
) {
 return nullptr;
   }
 
+  // Only 1 threads is required if P1689 per file mode.
+  NumThreads = 1;
+
   // There might be multiple jobs for a compilation. Extract the specified
   // output filename from the last job.
   auto LastCmd = C->getJobs().end();
@@ -867,13 +870,6 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
   // Print out the dependency results to STDOUT by default.
   SharedStream DependencyOS(llvm::outs());
 
-  DependencyScanningService Service(ScanMode, Format, OptimizeArgs,
-EagerLoadModules);
-  llvm::DefaultThreadPool Pool(llvm::hardware_concurrency(NumThreads));
-  std::vector> WorkerTools;
-  for (unsigned I = 0; I < Pool.getMaxConcurrency(); ++I)
-WorkerTools.push_back(std::make_unique(Service));
-
   std::vector Inputs =
   AdjustingCompilations->getAllCompileCommands();
 
@@ -893,102 +889,118 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
   if (Format == ScanningOutputFormat::Full)
 FD.emplace(ModuleName.empty() ? Inputs.size() : 0);
 
-  if (Verbose) {
-llvm::outs() << "Running clang-scan-deps on " << Inputs.size()
- << " files using " << Pool.getMaxConcurrency() << " 
workers\n";
-  }
-
-  llvm::Timer T;
-  T.startTimer();
-
-  for (unsigned I = 0; I < Pool.getMaxConcurrency(); ++I) {
-Pool.async([&, I]() {
-  llvm::DenseSet AlreadySeenModules;
-  while (auto MaybeInputIndex = GetNextInputIndex()) {
-size_t LocalIndex = *MaybeInputIndex;
-const tooling::CompileCommand *Input = [LocalIndex];
-std::string Filename = std::move(Input->Filename);
-std::string CWD = std::move(Input->Directory);
-
-std::optional MaybeModuleName;
-if (!ModuleName.empty())
-  MaybeModuleName = ModuleName;
-
-std::string OutputDir(ModuleFilesDir);
-if (OutputDir.empty())
-  OutputDir = getModuleCachePath(Input->CommandLine);
-auto LookupOutput = [&](const ModuleID , ModuleOutputKind MOK) {
-  return ::lookupModuleOutput(MID, MOK, OutputDir);
-};
-
-// Run the tool on it.
-if (Format == ScanningOutputFormat::Make) {
-  auto MaybeFile =
-  WorkerTools[I]->getDependencyFile(Input->CommandLine, CWD);
-  if (handleMakeDependencyToolResult(Filename, MaybeFile, DependencyOS,
- Errs))
-HadErrors = true;
-} else if (Format == ScanningOutputFormat::P1689) {
-  // It is useful to generate the make-format dependency output during
-  // the scanning for P1689. Otherwise the users need to scan again for
-  // it. We will generate the make-format dependency output if we find
-  // `-MF` in the command lines.
-  std::string MakeformatOutputPath;
-  std::string MakeformatOutput;
-
-  auto MaybeRule = WorkerTools[I]->getP1689ModuleDependencyFile(
-  *Input, CWD, MakeformatOutput, MakeformatOutputPath);
-
-  if (handleP1689DependencyToolResult(Filename, MaybeRule, PD, Errs))
-HadErrors = true;
+  std::vector> WorkerTools;
 
-  if (!MakeformatOutputPath.empty() && !MakeformatOutput.empty() &&
-  !HadErrors) {
-static std::mutex Lock;
-// With compilation database, we may open different files
-// concurrently or we may write the same file concurrently. So we
-// use a map here to allow multiple compile commands to write to 
the
-// same file. Also we need a lock here to avoid data race.
-static llvm::StringMap OSs;
-std::unique_lock LockGuard(Lock);
-
-auto OSIter = OSs.find(MakeformatOutputPath);
-if (OSIter == OSs.end()) {
-  std::error_code EC;
-  OSIter = OSs.try_emplace(MakeformatOutputPath,
-   MakeformatOutputPath, EC)
- 

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

2024-03-07 Thread Chuanqi Xu via cfe-commits

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


[clang] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use thread pool in P1689 per file mode (PR #84285)

2024-03-07 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 created 
https://github.com/llvm/llvm-project/pull/84285


I suddenly found that the clang scan deps may use all concurrent threads to 
scan the files. It makes sense in the batch mode. But in P1689 per file mode, 
it simply wastes times and resources.

This patch itself should be a NFC patch. It simply moves codes.

>From 8f3060da8059dc300152a1a1bc297cffcba51a61 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu 
Date: Thu, 7 Mar 2024 15:19:28 +0800
Subject: [PATCH] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use thread
 pool in P1689 per file mode

I suddenly found that the clang scan deps may use all concurrent threads
to scan the files. It makes sense in the batch mode. But in P1689
per file mode, it simply wastes times.
---
 clang/tools/clang-scan-deps/ClangScanDeps.cpp | 204 +-
 1 file changed, 108 insertions(+), 96 deletions(-)

diff --git a/clang/tools/clang-scan-deps/ClangScanDeps.cpp 
b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
index d042fecc3dbe63..843816a8ed6515 100644
--- a/clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -744,6 +744,9 @@ getCompilationDataBase(int argc, char **argv, std::string 
) {
 return nullptr;
   }
 
+  // Only 1 threads is required if P1689 per file mode.
+  NumThreads = 1;
+
   // There might be multiple jobs for a compilation. Extract the specified
   // output filename from the last job.
   auto LastCmd = C->getJobs().end();
@@ -867,13 +870,6 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
   // Print out the dependency results to STDOUT by default.
   SharedStream DependencyOS(llvm::outs());
 
-  DependencyScanningService Service(ScanMode, Format, OptimizeArgs,
-EagerLoadModules);
-  llvm::DefaultThreadPool Pool(llvm::hardware_concurrency(NumThreads));
-  std::vector> WorkerTools;
-  for (unsigned I = 0; I < Pool.getMaxConcurrency(); ++I)
-WorkerTools.push_back(std::make_unique(Service));
-
   std::vector Inputs =
   AdjustingCompilations->getAllCompileCommands();
 
@@ -893,102 +889,118 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
   if (Format == ScanningOutputFormat::Full)
 FD.emplace(ModuleName.empty() ? Inputs.size() : 0);
 
-  if (Verbose) {
-llvm::outs() << "Running clang-scan-deps on " << Inputs.size()
- << " files using " << Pool.getMaxConcurrency() << " 
workers\n";
-  }
-
-  llvm::Timer T;
-  T.startTimer();
-
-  for (unsigned I = 0; I < Pool.getMaxConcurrency(); ++I) {
-Pool.async([&, I]() {
-  llvm::DenseSet AlreadySeenModules;
-  while (auto MaybeInputIndex = GetNextInputIndex()) {
-size_t LocalIndex = *MaybeInputIndex;
-const tooling::CompileCommand *Input = [LocalIndex];
-std::string Filename = std::move(Input->Filename);
-std::string CWD = std::move(Input->Directory);
-
-std::optional MaybeModuleName;
-if (!ModuleName.empty())
-  MaybeModuleName = ModuleName;
-
-std::string OutputDir(ModuleFilesDir);
-if (OutputDir.empty())
-  OutputDir = getModuleCachePath(Input->CommandLine);
-auto LookupOutput = [&](const ModuleID , ModuleOutputKind MOK) {
-  return ::lookupModuleOutput(MID, MOK, OutputDir);
-};
-
-// Run the tool on it.
-if (Format == ScanningOutputFormat::Make) {
-  auto MaybeFile =
-  WorkerTools[I]->getDependencyFile(Input->CommandLine, CWD);
-  if (handleMakeDependencyToolResult(Filename, MaybeFile, DependencyOS,
- Errs))
-HadErrors = true;
-} else if (Format == ScanningOutputFormat::P1689) {
-  // It is useful to generate the make-format dependency output during
-  // the scanning for P1689. Otherwise the users need to scan again for
-  // it. We will generate the make-format dependency output if we find
-  // `-MF` in the command lines.
-  std::string MakeformatOutputPath;
-  std::string MakeformatOutput;
-
-  auto MaybeRule = WorkerTools[I]->getP1689ModuleDependencyFile(
-  *Input, CWD, MakeformatOutput, MakeformatOutputPath);
-
-  if (handleP1689DependencyToolResult(Filename, MaybeRule, PD, Errs))
-HadErrors = true;
+  std::vector> WorkerTools;
 
-  if (!MakeformatOutputPath.empty() && !MakeformatOutput.empty() &&
-  !HadErrors) {
-static std::mutex Lock;
-// With compilation database, we may open different files
-// concurrently or we may write the same file concurrently. So we
-// use a map here to allow multiple compile commands to write to 
the
-// same file. Also we need a lock here to avoid data race.
-static llvm::StringMap OSs;
-std::unique_lock LockGuard(Lock);
-
-auto 

[clang] [C++20][Coroutines] Lambda-coroutine with operator new in promise_type (PR #84193)

2024-03-06 Thread Chuanqi Xu via cfe-commits


@@ -6898,10 +6898,18 @@ class Sema final {
BinaryOperatorKind Operator);
 
    ActOnCXXThis -  Parse 'this' pointer.
-  ExprResult ActOnCXXThis(SourceLocation loc);
+  ///
+  /// \param SkipLambdaCaptureCheck Whether to skip the 'this' check for a
+  /// lambda because 'this' is the lambda's 'this'-pointer.
+  ExprResult ActOnCXXThis(SourceLocation loc,
+  bool SkipLambdaCaptureCheck = false);

ChuanqiXu9 wrote:

If there is any problem with the promise_type with a constructor, let's make it 
in other patches.

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


[clang] [C++20][Coroutines] Lambda-coroutine with operator new in promise_type (PR #84193)

2024-03-06 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 approved this pull request.

LGTM with the adding the comments.

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


[clang] [C++20][Coroutines] Lambda-coroutine with operator new in promise_type (PR #84193)

2024-03-06 Thread Chuanqi Xu via cfe-commits


@@ -6898,10 +6898,18 @@ class Sema final {
BinaryOperatorKind Operator);
 
    ActOnCXXThis -  Parse 'this' pointer.
-  ExprResult ActOnCXXThis(SourceLocation loc);
+  ///
+  /// \param SkipLambdaCaptureCheck Whether to skip the 'this' check for a
+  /// lambda because 'this' is the lambda's 'this'-pointer.
+  ExprResult ActOnCXXThis(SourceLocation loc,
+  bool SkipLambdaCaptureCheck = false);

ChuanqiXu9 wrote:

Excellent. Good. I suggest you to update this to the inline comments.

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


[clang] [C++20][Coroutines] Lambda-coroutine with operator new in promise_type (PR #84193)

2024-03-06 Thread Chuanqi Xu via cfe-commits


@@ -6898,10 +6898,18 @@ class Sema final {
BinaryOperatorKind Operator);
 
    ActOnCXXThis -  Parse 'this' pointer.
-  ExprResult ActOnCXXThis(SourceLocation loc);
+  ///
+  /// \param SkipLambdaCaptureCheck Whether to skip the 'this' check for a
+  /// lambda because 'this' is the lambda's 'this'-pointer.
+  ExprResult ActOnCXXThis(SourceLocation loc,
+  bool SkipLambdaCaptureCheck = false);

ChuanqiXu9 wrote:

Can we provide more rationale for skipping lambda's capture check here? For 
example, in what cases and for what reasons, we want to skip the check. I am 
still confused for that.

https://github.com/llvm/llvm-project/pull/84193
___
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)

2024-03-06 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

> Can we add a release note and documentation for this? Thanks!

The current patch is transparent to users and it is only part of the series 
patches. I'd like to document that after I made the series of patches.

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


[clang] d3df2a8 - [C++20] [Modules] Handle transitive import in the module properly

2024-03-05 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2024-03-06T15:46:55+08:00
New Revision: d3df2a834cf6febb44c699d109b9e7f622194837

URL: 
https://github.com/llvm/llvm-project/commit/d3df2a834cf6febb44c699d109b9e7f622194837
DIFF: 
https://github.com/llvm/llvm-project/commit/d3df2a834cf6febb44c699d109b9e7f622194837.diff

LOG: [C++20] [Modules] Handle transitive import in the module properly

Close https://github.com/llvm/llvm-project/issues/84002

Per [module.import]p7:

> Additionally, when a module-import-declaration in a module unit of
> some module M imports another module unit U of M, it also imports all
> translation units imported by non-exported module-import-declarations
> in the module unit purview of U.

However, we only tried to implement it during the implicit import of
primary module interface for module implementation unit.

Also we didn't implement the last sentence from [module.import]p7
completely:

> These rules can in turn lead to the importation of yet more
> translation units.

This patch tries to care the both issues.

Added: 
clang/test/Modules/transitive-import.cppm

Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/Module.h
clang/lib/Basic/Module.cpp
clang/lib/Sema/SemaModule.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 5e0352a7eaf6cd..b074055a4eaf69 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -86,6 +86,11 @@ C++20 Feature Support
 - Implemented the `__is_layout_compatible` intrinsic to support
   `P0466R5: Layout-compatibility and Pointer-interconvertibility Traits 
`_.
 
+- Clang now implements [module.import]p7 fully. Clang now will import module
+  units transitively for the module units coming from the same module of the
+  current module units.
+  Fixes `#84002 `_.
+
 C++23 Feature Support
 ^
 

diff  --git a/clang/include/clang/Basic/Module.h 
b/clang/include/clang/Basic/Module.h
index 30ec9c99315092..9f62c058ca0da0 100644
--- a/clang/include/clang/Basic/Module.h
+++ b/clang/include/clang/Basic/Module.h
@@ -598,6 +598,11 @@ class alignas(8) Module {
Kind == ModulePartitionImplementation;
   }
 
+  /// Is this a module partition implementation unit.
+  bool isModulePartitionImplementation() const {
+return Kind == ModulePartitionImplementation;
+  }
+
   /// Is this a module implementation.
   bool isModuleImplementation() const {
 return Kind == ModuleImplementationUnit;
@@ -853,12 +858,6 @@ class VisibleModuleSet {
   VisibleCallback Vis = [](Module *) {},
   ConflictCallback Cb = [](ArrayRef, Module *,
StringRef) {});
-
-  /// Make transitive imports visible for [module.import]/7.
-  void makeTransitiveImportsVisible(
-  Module *M, SourceLocation Loc, VisibleCallback Vis = [](Module *) {},
-  ConflictCallback Cb = [](ArrayRef, Module *, StringRef) {});
-
 private:
   /// Import locations for each visible module. Indexed by the module's
   /// VisibilityID.

diff  --git a/clang/lib/Basic/Module.cpp b/clang/lib/Basic/Module.cpp
index 1c5043a618fff3..9f597dcf8b0f5a 100644
--- a/clang/lib/Basic/Module.cpp
+++ b/clang/lib/Basic/Module.cpp
@@ -722,14 +722,6 @@ void VisibleModuleSet::setVisible(Module *M, 
SourceLocation Loc,
   VisitModule({M, nullptr});
 }
 
-void VisibleModuleSet::makeTransitiveImportsVisible(Module *M,
-SourceLocation Loc,
-VisibleCallback Vis,
-ConflictCallback Cb) {
-  for (auto *I : M->Imports)
-setVisible(I, Loc, Vis, Cb);
-}
-
 ASTSourceDescriptor::ASTSourceDescriptor(Module )
 : Signature(M.Signature), ClangModule() {
   if (M.Directory)

diff  --git a/clang/lib/Sema/SemaModule.cpp b/clang/lib/Sema/SemaModule.cpp
index ed7f626971f345..f08c1cb3a13ef5 100644
--- a/clang/lib/Sema/SemaModule.cpp
+++ b/clang/lib/Sema/SemaModule.cpp
@@ -73,6 +73,90 @@ static std::string stringFromPath(ModuleIdPath Path) {
   return Name;
 }
 
+/// Helper function for makeTransitiveImportsVisible to decide whether
+/// the \param Imported module unit is in the same module with the \param
+/// CurrentModule.
+/// \param FoundPrimaryModuleInterface is a helper parameter to record the
+/// primary module interface unit corresponding to the module \param
+/// CurrentModule. Since currently it is expensive to decide whether two module
+/// units come from the same module by comparing the module name.
+static bool
+isImportingModuleUnitFromSameModule(Module *Imported, Module *CurrentModule,
+Module *) {
+  if (!Imported->isNamedModule())
+return false;
+
+  // The a partition unit we're importing must be in 

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

2024-03-05 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

I am going to land this in the week later if no objections come in. I think it 
is necessary to land the series of patches (to reduce the contents of BMI) for 
clang19. And of course, the functionality will be opt in for one~two releases 
for experimental.

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


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

2024-03-05 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

> Do you expect to make any changes to type streaming?

I don't expect to do that explicitly. The number of types deserialized can be 
decreased naturally after we avoid emitting declarations during the writing.

https://github.com/llvm/llvm-project/pull/75894
___
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)

2024-03-05 Thread Chuanqi Xu via cfe-commits


@@ -830,6 +843,19 @@ class PCHGenerator : public SemaConsumer {
   bool hasEmittedPCH() const { return Buffer->IsComplete; }
 };
 
+class ReducedBMIGenerator : public PCHGenerator {
+public:
+  ReducedBMIGenerator(const Preprocessor , InMemoryModuleCache ,
+  StringRef OutputFile, std::shared_ptr Buffer,
+  bool IncludeTimestamps);
+
+  void HandleTranslationUnit(ASTContext ) override;
+};
+
+/// If the definition may impact the ABI. If yes, we're allowed to eliminate
+/// the definition of D in reduced BMI.
+bool MayDefAffectABI(const Decl *D);

ChuanqiXu9 wrote:

Nice catch up.

I changed the name to `CanElideDeclDef` and the comments to:

```
/// If we can elide the definition of \param D in reduced BMI.
///
/// Generally, we can elide the definition of a declaration if it won't affect 
the
/// ABI. e.g., the non-inline function bodies.
```

Hope this to be clear.

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


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

2024-03-05 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

> * I do not want to block progress, so let's move forward with this patch for 
> now.

Yeah. Great to see we have some progress finally. I think this is really 
important since I see more and more peope complaninig the performance for 
modules. I feel this series patch is key to to improve the user's impression 
that named modules are just purely wrappers for PCH.

> * It seems to me (as we found with GMF decl elision) that the process is 
> quite a bit more complex than simply omitting a decl.  We need to elide other 
> decls that are then unused (e.g. decls local to an elided function body) and 
> also avoid emitting types that are now no longer existent.

After looking into the codes more, I changed my mind for this. I feel it is the 
most efficient and the most natural way to omit declarations in ASTWriter.

The idea is, previously, we'll start to write declarations in the current TU 
from the first declarations. And in the C++20 named modules world, we would 
start to write declarations from the first declarations in the global module 
fragment.  And we can implement GMF decl elision naturally by writing 
declarations from the first declaration in the module purview and only write 
the referenced decl from the GMF during the writing process. This is super 
natural and efficient.

> 
> The process seems to me to be either one of:
> 
> * rewriting the AST (which is why my patch set picked the use of the plugin 
> API since that is the purpose there).
> * walking the AST and marking entities as used / not used / elided.

Now I doubt both of the method to be not efficiency and it adds additional 
burdens to the developers and the users.

> 
> It still feels to me to be better to have clear separation of this work from 
> the work of streaming - but if we can make clear layers within the streaming, 
> then maybe the maintenance will not be too hard.

I think the maintainance may not be too hard in that way. ASTWriter is not such 
a devil :) Probably we need some refactoration in the serialization to make 
codes more clear. But the point is that we must get the ASTWriter/ASTReader 
involved. It may not be a good idea to leave the ASTWriter/ASTReader as is and 
add another layer... 

For example, it should be better to not deserialize the declaration from the 
very beginning instead of deserializing the declaration and judge that it is 
not wanted/visible. And to achieve this, we must  touch the serialization layer 
deeply.



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


[clang] [clang][NFC] Format clang/lib/Sema/Sema.cpp (PR #83974)

2024-03-05 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

> Thank you for references both.
> 
> Actually, I'd like to have PR like #83961. Is it acceptable to merge this 
> kind of PR in that case then?

I don't feel the patches are related. I think you can only format the changed 
lines.

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


[clang] [clang][NFC] Format clang/lib/Sema/Sema.cpp (PR #83974)

2024-03-05 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

Oh, I found it here: https://llvm.org/docs/CodingStandards.html#introduction

> Our long term goal is for the entire codebase to follow the convention, but 
> we explicitly do not want patches that do large-scale reformatting of 
> existing code.

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


[clang] [clang][NFC] Format clang/lib/Sema/Sema.cpp (PR #83974)

2024-03-05 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

I remember we have policies that we don't like patches which purely formats 
codes. It makes backporting and cherry-picking harder. But I can't find the 
wording now.

CC: @AaronBallman @Endilll 

https://github.com/llvm/llvm-project/pull/83974
___
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)

2024-03-04 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 commented:

Thanks. This looks good to me except few nit comments.

Have you tested on a real world workloads?

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


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

2024-03-04 Thread Chuanqi Xu via cfe-commits


@@ -167,6 +167,53 @@ class CoroCloner {
 
 } // end anonymous namespace
 
+// FIXME:
+// Lower the intrinisc in CoroEarly phase if coroutine frame doesn't escape
+// and it is known that other transformations, for example, sanitizers
+// won't lead to incorrect code.
+static void lowerAwaitSuspend(IRBuilder<> , CoroAwaitSuspendInst *CB) {
+  auto Wrapper = CB->getWrapperFunction();
+  auto Awaiter = CB->getAwaiter();
+  auto FramePtr = CB->getFrame();
+
+  Builder.SetInsertPoint(CB);
+
+  CallBase *NewCall = nullptr;
+  if (auto Invoke = dyn_cast(CB)) {
+auto WrapperInvoke =
+Builder.CreateInvoke(Wrapper, Invoke->getNormalDest(),
+ Invoke->getUnwindDest(), {Awaiter, FramePtr});
+
+WrapperInvoke->setCallingConv(Invoke->getCallingConv());
+std::copy(Invoke->bundle_op_info_begin(), Invoke->bundle_op_info_end(),
+  WrapperInvoke->bundle_op_info_begin());
+AttributeList NewAttributes =
+Invoke->getAttributes().removeParamAttributes(Invoke->getContext(), 2);

ChuanqiXu9 wrote:

What is the attribute to be removed? Let's add a comment here to make it clear.

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)

2024-03-04 Thread Chuanqi Xu via cfe-commits


@@ -338,6 +414,71 @@ static QualType getCoroutineSuspendExprReturnType(const 
ASTContext ,
 }
 #endif
 
+llvm::Function *
+CodeGenFunction::generateAwaitSuspendWrapper(Twine const ,
+ Twine const ,
+ CoroutineSuspendExpr const ) {
+  std::string FuncName = "__await_suspend_wrapper_";
+  FuncName += CoroName.str();
+  FuncName += '_';
+  FuncName += SuspendPointName.str();
+
+  ASTContext  = getContext();
+
+  FunctionArgList args;
+
+  ImplicitParamDecl AwaiterDecl(C, C.VoidPtrTy, ImplicitParamKind::Other);
+  ImplicitParamDecl FrameDecl(C, C.VoidPtrTy, ImplicitParamKind::Other);
+  QualType ReturnTy = S.getSuspendExpr()->getType();
+
+  args.push_back();
+  args.push_back();
+
+  const CGFunctionInfo  =
+  CGM.getTypes().arrangeBuiltinFunctionDeclaration(ReturnTy, args);
+
+  llvm::FunctionType *LTy = CGM.getTypes().GetFunctionType(FI);
+
+  llvm::Function *Fn = llvm::Function::Create(
+  LTy, llvm::GlobalValue::PrivateLinkage, FuncName, ());
+
+  Fn->addParamAttr(0, llvm::Attribute::AttrKind::NonNull);
+  Fn->addParamAttr(0, llvm::Attribute::AttrKind::NoUndef);
+
+  Fn->addParamAttr(1, llvm::Attribute::AttrKind::NoUndef);
+
+  Fn->setMustProgress();
+  Fn->addFnAttr(llvm::Attribute::AttrKind::AlwaysInline);
+
+  StartFunction(GlobalDecl(), ReturnTy, Fn, FI, args);
+
+  llvm::Value *AwaiterPtr = 
Builder.CreateLoad(GetAddrOfLocalVar());
+  auto AwaiterLValue =
+  MakeNaturalAlignAddrLValue(AwaiterPtr, AwaiterDecl.getType());
+
+  CurAwaitSuspendWrapper.FramePtr =
+  Builder.CreateLoad(GetAddrOfLocalVar());
+
+  // FIXME: mark as aliasing with frame?
+  // FIXME: TBAA?
+  // FIXME: emit in a better way (maybe egenerate AST in SemaCoroutine)?

ChuanqiXu9 wrote:

Generally we like comments in a more formal style. Please rewrite the comments 
to make it more expressive.

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)

2024-03-04 Thread Chuanqi Xu via cfe-commits

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] [clang-tools-extra] [libcxx] [clang] Enable sized deallocation by default in C++14 onwards (PR #83774)

2024-03-03 Thread Chuanqi Xu via cfe-commits


@@ -72,6 +72,10 @@ sections with improvements to Clang's support for those 
languages.
 C++ Language Changes
 
 
+C++14 Feature Support
+^
+- Sized deallocation is enabled by default in C++14 onwards.

ChuanqiXu9 wrote:

It may be good to mention the flag enabled so that people met regression can 
disable it locally to workaround it.

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


[clang] [clang-tools-extra] [libcxx] [clang] Enable sized deallocation by default in C++14 onwards (PR #83774)

2024-03-03 Thread Chuanqi Xu via cfe-commits


@@ -0,0 +1,44 @@
+//===--- SizedDellocation.h - Sized Deallocation *- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+///
+/// \file
+/// Defines a function that returns the minimum OS versions supporting
+/// C++14's sized deallocation functions.
+///
+//===--===//
+
+#ifndef LLVM_CLANG_BASIC_SIZEDDEALLOCATION_H
+#define LLVM_CLANG_BASIC_SIZEDDEALLOCATION_H
+
+#include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/VersionTuple.h"
+#include "llvm/TargetParser/Triple.h"
+
+namespace clang {
+inline llvm::VersionTuple sizedDeallocMinVersion(llvm::Triple::OSType OS) {

ChuanqiXu9 wrote:

If I read correctly, this is only used in `Darwin.cpp`, so it would be better 
to inline the function there.

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


[clang] Reland "[clang][modules] Print library module manifest path." (PR #82160)

2024-02-27 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

@mordante if we want this for 18, we need to land and backport it in this week.

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


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

2024-02-27 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

> That'd mean that we "just" need to replace LazySpecializationInfo 
> *LazySpecializations = nullptr; with the on-disk hash table approach. That 
> would probably require centralizing that logic somewhere in the ASTReader 
> (the way this PR does) but with minimal changes wrt D41416.

@vgvassilev Let me try to double check your advice. In you suggestion, you 
suggest to replace `LazySpecializationInfo *LazySpecializations` with an 
on-disk hash map from an integer (hash value for template args) to  
LazySpecializationInfo in D41416 instead of another integer (DeclID, just like 
my patch)?

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


[clang] D41416: [modules] [pch] Do not deserialize all lazy template specializations when looking for one. (PR #83108)

2024-02-26 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 updated 
https://github.com/llvm/llvm-project/pull/83108

>From 59e1880df74434e3c446705788d92b5949d99536 Mon Sep 17 00:00:00 2001
From: Vassil Vassilev 
Date: Sun, 7 Jan 2018 15:16:11 +0200
Subject: [PATCH 1/3] D41416: [modules] [pch] Do not deserialize all lazy
 template specializations when looking for one.

---
 clang/include/clang/AST/DeclTemplate.h| 36 -
 clang/lib/AST/DeclTemplate.cpp| 96 +--
 clang/lib/AST/ODRHash.cpp | 15 
 clang/lib/Serialization/ASTReader.cpp | 25 --
 clang/lib/Serialization/ASTReaderDecl.cpp | 36 ++---
 clang/lib/Serialization/ASTWriter.cpp | 21 -
 clang/lib/Serialization/ASTWriterDecl.cpp | 74 ++---
 7 files changed, 242 insertions(+), 61 deletions(-)

diff --git a/clang/include/clang/AST/DeclTemplate.h 
b/clang/include/clang/AST/DeclTemplate.h
index e3b6a7efb1127a..4ed9b58d4ff609 100644
--- a/clang/include/clang/AST/DeclTemplate.h
+++ b/clang/include/clang/AST/DeclTemplate.h
@@ -256,6 +256,9 @@ class TemplateArgumentList final
   TemplateArgumentList(const TemplateArgumentList &) = delete;
   TemplateArgumentList =(const TemplateArgumentList &) = delete;
 
+  /// Create hash for the given arguments.
+  static unsigned ComputeODRHash(ArrayRef Args);
+
   /// Create a new template argument list that copies the given set of
   /// template arguments.
   static TemplateArgumentList *CreateCopy(ASTContext ,
@@ -730,6 +733,26 @@ class RedeclarableTemplateDecl : public TemplateDecl,
   }
 
   void anchor() override;
+  struct LazySpecializationInfo {
+uint32_t DeclID = ~0U;
+unsigned ODRHash = ~0U;
+bool IsPartial = false;
+LazySpecializationInfo(uint32_t ID, unsigned Hash = ~0U,
+   bool Partial = false)
+  : DeclID(ID), ODRHash(Hash), IsPartial(Partial) { }
+LazySpecializationInfo() { }
+bool operator<(const LazySpecializationInfo ) const {
+  return DeclID < Other.DeclID;
+}
+bool operator==(const LazySpecializationInfo ) const {
+  assert((DeclID != Other.DeclID || ODRHash == Other.ODRHash) &&
+ "Hashes differ!");
+  assert((DeclID != Other.DeclID || IsPartial == Other.IsPartial) &&
+ "Both must be the same kinds!");
+  return DeclID == Other.DeclID;
+}
+  };
+
 protected:
   template  struct SpecEntryTraits {
 using DeclType = EntryType;
@@ -770,7 +793,12 @@ class RedeclarableTemplateDecl : public TemplateDecl,
 return SpecIterator(isEnd ? Specs.end() : Specs.begin());
   }
 
-  void loadLazySpecializationsImpl() const;
+  void loadLazySpecializationsImpl(bool OnlyPartial = false) const;
+
+  void loadLazySpecializationsImpl(llvm::ArrayRef Args,
+   TemplateParameterList *TPL = nullptr) const;
+
+  Decl *loadLazySpecializationImpl(LazySpecializationInfo ) const;
 
   template 
   typename SpecEntryTraits::DeclType*
@@ -797,7 +825,7 @@ class RedeclarableTemplateDecl : public TemplateDecl,
 ///
 /// The first value in the array is the number of specializations/partial
 /// specializations that follow.
-uint32_t *LazySpecializations = nullptr;
+LazySpecializationInfo *LazySpecializations = nullptr;
 
 /// The set of "injected" template arguments used within this
 /// template.
@@ -2268,7 +2296,7 @@ class ClassTemplateDecl : public RedeclarableTemplateDecl 
{
   friend class TemplateDeclInstantiator;
 
   /// Load any lazily-loaded specializations from the external source.
-  void LoadLazySpecializations() const;
+  void LoadLazySpecializations(bool OnlyPartial = false) const;
 
   /// Get the underlying class declarations of the template.
   CXXRecordDecl *getTemplatedDecl() const {
@@ -3039,7 +3067,7 @@ class VarTemplateDecl : public RedeclarableTemplateDecl {
   friend class ASTDeclWriter;
 
   /// Load any lazily-loaded specializations from the external source.
-  void LoadLazySpecializations() const;
+  void LoadLazySpecializations(bool OnlyPartial = false) const;
 
   /// Get the underlying variable declarations of the template.
   VarDecl *getTemplatedDecl() const {
diff --git a/clang/lib/AST/DeclTemplate.cpp b/clang/lib/AST/DeclTemplate.cpp
index 3c217d6a6a5ae3..1babe39ee2a7e5 100644
--- a/clang/lib/AST/DeclTemplate.cpp
+++ b/clang/lib/AST/DeclTemplate.cpp
@@ -20,6 +20,8 @@
 #include "clang/AST/TemplateBase.h"
 #include "clang/AST/TemplateName.h"
 #include "clang/AST/Type.h"
+#include "clang/AST/ODRHash.h"
+#include "clang/AST/ExprCXX.h"
 #include "clang/AST/TypeLoc.h"
 #include "clang/Basic/Builtins.h"
 #include "clang/Basic/LLVM.h"
@@ -331,16 +333,43 @@ RedeclarableTemplateDecl::CommonBase 
*RedeclarableTemplateDecl::getCommonPtr() c
   return Common;
 }
 
-void RedeclarableTemplateDecl::loadLazySpecializationsImpl() const {
+void RedeclarableTemplateDecl::loadLazySpecializationsImpl(
+ bool OnlyPartial/*=false*/) const 
{
   // Grab 

[clang] D41416: [modules] [pch] Do not deserialize all lazy template specializations when looking for one. (PR #83108)

2024-02-26 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

Weird. I only see two failures in my local environment:

```
Failed Tests (2):
  Clang :: Modules/cxx-templates.cpp
  Clang :: Modules/odr_hash.cpp
```

And I saw both of them in my patch. It is simply order mismatches.

https://github.com/llvm/llvm-project/pull/83108
___
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)

2024-02-26 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

Oh, I didn't notice you've removed D153003 already. But the branch name looks 
not good. So I've created a pr in 
https://github.com/llvm/llvm-project/pull/83108

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


[clang] D41416: [modules] [pch] Do not deserialize all lazy template specializations when looking for one. (PR #83108)

2024-02-26 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

Personally I feel this patch is good and the testing result from our workload 
shows it is good too. But it looks like the performance testing results from 
google @zygoloid @ilya-biryukov is not good. So maybe we need to wait for 
landing this. (It will be great if @ilya-biryukov would like to test again)

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


[clang] D41416: [modules] [pch] Do not deserialize all lazy template specializations when looking for one. (PR #83108)

2024-02-26 Thread Chuanqi Xu via cfe-commits

https://github.com/ChuanqiXu9 created 
https://github.com/llvm/llvm-project/pull/83108

This from https://reviews.llvm.org/D41416. And we plan to introduce on disk 
hash table based on this. See https://github.com/llvm/llvm-project/pull/76774.

Following off are cited from https://reviews.llvm.org/D41416:

Currently, we load all lazy template specializations when we search whether 
there is a suitable template specialization for a template. This is especially 
suboptimal with modules. If module B specializes a template from module A the 
ASTReader would only read the specialization DeclID. This is observed to be 
especially pathological when module B is stl. However, the template 
instantiator (almost immediately after) will call findSpecialization. In turn, 
findSpecialization will load all lazy specializations to give an answer.

This patch teaches findSpecialization to work with lazy specializations without 
having to deserialize their full content. It provides along with the DeclID an 
cross-TU stable ODRHash of the template arguments which is enough to decide if 
we have already specialization and which are the exact ones (we load all decls 
with the same hash to avoid potential collisions) to deserialize.

While we make finding a template specialization more memory-efficient we are 
far from being done. There are still a few places which trigger eager 
deserialization of template specializations: the places where we require 
completion of the redeclaration chain.



>From 59e1880df74434e3c446705788d92b5949d99536 Mon Sep 17 00:00:00 2001
From: Vassil Vassilev 
Date: Sun, 7 Jan 2018 15:16:11 +0200
Subject: [PATCH] D41416: [modules] [pch] Do not deserialize all lazy template
 specializations when looking for one.

---
 clang/include/clang/AST/DeclTemplate.h| 36 -
 clang/lib/AST/DeclTemplate.cpp| 96 +--
 clang/lib/AST/ODRHash.cpp | 15 
 clang/lib/Serialization/ASTReader.cpp | 25 --
 clang/lib/Serialization/ASTReaderDecl.cpp | 36 ++---
 clang/lib/Serialization/ASTWriter.cpp | 21 -
 clang/lib/Serialization/ASTWriterDecl.cpp | 74 ++---
 7 files changed, 242 insertions(+), 61 deletions(-)

diff --git a/clang/include/clang/AST/DeclTemplate.h 
b/clang/include/clang/AST/DeclTemplate.h
index e3b6a7efb1127a..4ed9b58d4ff609 100644
--- a/clang/include/clang/AST/DeclTemplate.h
+++ b/clang/include/clang/AST/DeclTemplate.h
@@ -256,6 +256,9 @@ class TemplateArgumentList final
   TemplateArgumentList(const TemplateArgumentList &) = delete;
   TemplateArgumentList =(const TemplateArgumentList &) = delete;
 
+  /// Create hash for the given arguments.
+  static unsigned ComputeODRHash(ArrayRef Args);
+
   /// Create a new template argument list that copies the given set of
   /// template arguments.
   static TemplateArgumentList *CreateCopy(ASTContext ,
@@ -730,6 +733,26 @@ class RedeclarableTemplateDecl : public TemplateDecl,
   }
 
   void anchor() override;
+  struct LazySpecializationInfo {
+uint32_t DeclID = ~0U;
+unsigned ODRHash = ~0U;
+bool IsPartial = false;
+LazySpecializationInfo(uint32_t ID, unsigned Hash = ~0U,
+   bool Partial = false)
+  : DeclID(ID), ODRHash(Hash), IsPartial(Partial) { }
+LazySpecializationInfo() { }
+bool operator<(const LazySpecializationInfo ) const {
+  return DeclID < Other.DeclID;
+}
+bool operator==(const LazySpecializationInfo ) const {
+  assert((DeclID != Other.DeclID || ODRHash == Other.ODRHash) &&
+ "Hashes differ!");
+  assert((DeclID != Other.DeclID || IsPartial == Other.IsPartial) &&
+ "Both must be the same kinds!");
+  return DeclID == Other.DeclID;
+}
+  };
+
 protected:
   template  struct SpecEntryTraits {
 using DeclType = EntryType;
@@ -770,7 +793,12 @@ class RedeclarableTemplateDecl : public TemplateDecl,
 return SpecIterator(isEnd ? Specs.end() : Specs.begin());
   }
 
-  void loadLazySpecializationsImpl() const;
+  void loadLazySpecializationsImpl(bool OnlyPartial = false) const;
+
+  void loadLazySpecializationsImpl(llvm::ArrayRef Args,
+   TemplateParameterList *TPL = nullptr) const;
+
+  Decl *loadLazySpecializationImpl(LazySpecializationInfo ) const;
 
   template 
   typename SpecEntryTraits::DeclType*
@@ -797,7 +825,7 @@ class RedeclarableTemplateDecl : public TemplateDecl,
 ///
 /// The first value in the array is the number of specializations/partial
 /// specializations that follow.
-uint32_t *LazySpecializations = nullptr;
+LazySpecializationInfo *LazySpecializations = nullptr;
 
 /// The set of "injected" template arguments used within this
 /// template.
@@ -2268,7 +2296,7 @@ class ClassTemplateDecl : public RedeclarableTemplateDecl 
{
   friend class TemplateDeclInstantiator;
 
   /// Load any lazily-loaded specializations from the external source.
-  void LoadLazySpecializations() 

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

2024-02-26 Thread Chuanqi Xu via cfe-commits

ChuanqiXu9 wrote:

@rjmccall @dwblaikie 

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


[clang] Issue #63106: [сlang] Representation of ellipsis in AST (PR #80976)

2024-02-26 Thread Chuanqi Xu via cfe-commits


@@ -41,7 +41,7 @@ void TestCatch2() {
   try {
   }
 // CHECK-NEXT:CXXCatchStmt
-// CHECK-NEXT:  NULL
+// CHECK-NEXT:  VarDecl {{.*}} ''

ChuanqiXu9 wrote:

Maybe we can improve to print this.

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


[clang] Issue #63106: [сlang] Representation of ellipsis in AST (PR #80976)

2024-02-26 Thread Chuanqi Xu via cfe-commits


@@ -1053,6 +1053,10 @@ class VarDecl : public DeclaratorDecl, public 
Redeclarable {
 LLVM_PREFERRED_TYPE(bool)
 unsigned ExceptionVar : 1;
 
+/// To Check the ellipsis
+LLVM_PREFERRED_TYPE(bool)
+unsigned EllipsisVar : 1;

ChuanqiXu9 wrote:

Should we move this to `ParmVarDeclBitfields`?

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


[clang] Issue #63106: [сlang] Representation of ellipsis in AST (PR #80976)

2024-02-26 Thread Chuanqi Xu via cfe-commits


@@ -16983,7 +16983,7 @@ VarDecl *Sema::BuildExceptionDeclaration(Scope *S,
 
 /// ActOnExceptionDeclarator - Parsed the exception-declarator in a C++ catch
 /// handler.
-Decl *Sema::ActOnExceptionDeclarator(Scope *S, Declarator ) {
+Decl *Sema::ActOnExceptionDeclarator(Scope *S, Declarator , bool isCatchAll) 
{

ChuanqiXu9 wrote:

I am hesitate on this. IIUC, previously the `catch(...)` format is reprensented 
as the exception decl as nullptr? Then if yes, we should be able to reuse that.

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


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