https://github.com/ChuanqiXu9 approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/141890
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
@mathstuf in
https://github.com/llvm/llvm-project/issues/140825#issuecomment-2900112555 ,
xmake dev said he can fix the problem by `/clang:-o`. I am wondering if you can
did similar thing in CMake if there is an argument?
https://github.com/llvm/llvm-project/pull/121046
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/131569
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 approved this pull request.
https://github.com/llvm/llvm-project/pull/131569
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -654,6 +654,10 @@ class ASTReader
/// Map from the TU to its lexical contents from each module file.
std::vector> TULexicalDecls;
+ unsigned HeaderFileInfoIdx = 0;
ChuanqiXu9 wrote:
And also, this seems unsafe since ModuleManager can remove modules te
@@ -6831,43 +6832,60 @@ std::optional
ASTReader::isPreprocessedEntityInFileID(unsigned Index,
return false;
}
-namespace {
-
- /// Visitor used to search for information about a header file.
- class HeaderFileInfoVisitor {
- FileEntryRef FE;
-std::optional HFI;
-
-
@@ -654,6 +654,10 @@ class ASTReader
/// Map from the TU to its lexical contents from each module file.
std::vector> TULexicalDecls;
+ unsigned HeaderFileInfoIdx = 0;
ChuanqiXu9 wrote:
nit: Unloaded header file info idx.
And also I feel the name is odd.
https://github.com/ChuanqiXu9 commented:
> It turns out to be kind of a pain to use with HeaderFileInfoTrait. More
> importantly, we can't really afford to key by the internal key type since
> that only hashes on the size of the file and the hash collision gets pretty
> bad. Moreover, the mer
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/140867
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 approved this pull request.
https://github.com/llvm/llvm-project/pull/140373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
BTW, I don't mind landing the rest 3 patches since they are "verified".
https://github.com/llvm/llvm-project/pull/133057
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi
ChuanqiXu9 wrote:
> ### Performance measurements with LLVM
> I tested these patches for building LLVM itself with modules
> (`LLVM_ENABLE_MODULES=ON`). To work around #130795, I apply #131354 before
> building Clang. In terms of overall performance for the entire build, I'm not
> able to measu
@@ -1599,9 +1599,14 @@ CodeGenFunction::EmitAutoVarAlloca(const VarDecl &D) {
bool IsMSCatchParam =
D.isExceptionVariable() && getTarget().getCXXABI().isMicrosoft();
+ // No lifetime intrinsics on coroutine promise alloca, or middle end
+ // passes wi
ChuanqiXu9 wrote:
> Is `-Fo` even relevant here? The BMI output name comes from `-ifcOutput` (or
> `-fmodule-output=`). Consumption of external modules doesn't need an object,
> so it would only use `-fmodule-output=`.
>
> > Sorry, I don't remember seeing that discussion
>
> See this thread:
ChuanqiXu9 wrote:
> > @zmodem given how important this it, I hope we can make this for clang21.
> > Thanks!
>
> I'm just a reviewer here, and I still find the patch very confusing.
Not asking for an approval. It is just a ping : )
>
> And taking a step back, the whole point of clang-cl is to
ChuanqiXu9 wrote:
> Sorry, I don't remember seeing that discussion, and I'm probably missing lots
> of modules context. As a counter argument, clang-cl uses `/Yc` and `/Fp` to
> generate PCH files, to match MSVC's interface although the file format is
> different.
>
> More importantly, it fee
ChuanqiXu9 wrote:
> @emaxx-google, @ilya-biryukov, do you think we can move forward even though
> don't have a reproducer yet? It feels we are stuck on that one case on a
> downstream client -- worst case maybe the devs can work it around by changing
> source code for that one case?
Yes, I'm
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/130712
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 approved this pull request.
https://github.com/llvm/llvm-project/pull/130712
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
> Hi, this is my first contribution in LLVM. I would like to know ho many
> approves needed and is there anything else needed on my side? Thanks!
I think they just forgot to check if you have the write access. I think this is
good to merge if you fixed the CI or make sure it
ChuanqiXu9 wrote:
I just got a case:
```
class A {
public:
class B {
public:
B(A *);
// some non static data fields
};
B b(this);
};
```
Does this a valid prove that this optimization is not valid ?
https://github.com/llvm/llvm-project/pull/136792
__
@@ -14,3 +14,11 @@
//--- test.pcm
// CPP20WARNING-NOT: clang-cl: warning: argument unused during compilation:
'/std:c++20' [-Wunused-command-line-argument]
+
+// test whether the following outputs %Hello.bmi
+// RUN: %clang_cl /std:c++20 --precompile -x c++-module
-fmodule-o
Author: Chuanqi Xu
Date: 2025-05-07T14:47:24+08:00
New Revision: 2d81994c4a41b950eed9bdee189cba9d00381b58
URL:
https://github.com/llvm/llvm-project/commit/2d81994c4a41b950eed9bdee189cba9d00381b58
DIFF:
https://github.com/llvm/llvm-project/commit/2d81994c4a41b950eed9bdee189cba9d00381b58.diff
LO
ChuanqiXu9 wrote:
hmmm for `test case`, I mean a test case in clang, either a unit test or a lit
test, so we can understand the effect on users more clearly.
And if you're talking about the general code policy, I'll suggest you to
https://discourse.llvm.org/ to make it more verbose.
https://
ChuanqiXu9 wrote:
I feel `.clear()` should have a similar semantic with `= {};`. It will be
confusing for people to understand this. It will be helpful if you can provide
a test to show the difference.
https://github.com/llvm/llvm-project/pull/138256
___
https://github.com/ChuanqiXu9 commented:
Could you elaborate? Why `= {}` is better than `.clear()` ?
https://github.com/llvm/llvm-project/pull/138256
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
ChuanqiXu9 wrote:
LGTM. Let's land this in individual commits after the large test in google
finish.
https://github.com/llvm/llvm-project/pull/133057
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listin
@@ -21,17 +21,6 @@ using namespace clang;
namespace {
class TemplateArgumentHasher {
- // If we bail out during the process of calculating hash values for
- // template arguments for any reason. We're allowed to do it since
- // TemplateArgumentHasher are only required to g
@@ -477,21 +476,21 @@ When the ``-fmodules-embed-all-files`` flag are enabled,
Clang explicitly emits
code into the BMI file, the contents of the BMI file contain a sufficiently
verbose
representation to reproduce the original source file.
-:sup:`1`` Input files: The source
@@ -477,21 +476,21 @@ When the ``-fmodules-embed-all-files`` flag are enabled,
Clang explicitly emits
code into the BMI file, the contents of the BMI file contain a sufficiently
verbose
representation to reproduce the original source file.
-:sup:`1`` Input files: The source
https://github.com/ChuanqiXu9 approved this pull request.
I am not a native speaker. So LGTM generally.
https://github.com/llvm/llvm-project/pull/136719
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/136719
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/135887
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 approved this pull request.
Yeah, I have some concern about the interface. But I am in the camp that we'd
better to get best practice from practice instead of pure imagination. And
given Meta is doing the experiments in practice, I think it is fine to let it
go.
ChuanqiXu9 wrote:
> Going back to the idea of not writing the paths of imported PCMs at all;
> currently the condition to not write the paths is if the imported PCM is a
> named module. Perhaps this condition can be extended to omit the paths if the
> PCM was found through `-fmodule-file==`?
ChuanqiXu9 wrote:
> Separately, even with named modules, with or without
> `-fmodules-embed-all-files`, the `INPUT_FILE` paths in the PCM are still
> absolute. I guess with `-fmodules-embed-all-files` those paths are not used
> since the source files are embedded, which I suppose is how it avo
ChuanqiXu9 wrote:
> > BTW, I think `-fmodule-file=` is not a suggested way to introduce BMIs. It
> > will load the BMIs eagerly. And for named modules, we will load them lazily
> > according to their name. For header units, may be we can do something with
> > FID. It matters for cases like:
>
ChuanqiXu9 wrote:
> > If you did `-fmodule-file==` for header units, I think it is
> > better to upstream that first. I think it is more fundamental.
>
> We don't do anything special downstream. As far as I know it already works
> today.
If `-fmodule-file==` already works for header units, it
https://github.com/ChuanqiXu9 commented:
Didn't take a close look. But I don't feel we shall do it behind a flag. I
think we should make BMI of C++20 modules (at least C++20 named modules)
relocatable.
In our downstream, IIUC, we make it by always enabling
"-fmodules-embed-all-files " . See d
ChuanqiXu9 wrote:
I received a mail but not see it in the web page. Is something going wrong.
https://github.com/llvm/llvm-project/pull/133462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-c
https://github.com/ChuanqiXu9 approved this pull request.
Let it go.
https://github.com/llvm/llvm-project/pull/132214
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 commented:
LGTM.
But I didn't recognize you didn't update `MultiplexExternalSemaSource`. Every
time we add new interface to `ExternalASTSource`, we need to update
`MultiplexExternalSemaSource` too.
https://github.com/llvm/llvm-project/pull/132214
https://github.com/ChuanqiXu9 commented:
Thanks. What I feel not good is passing `ExpectedName` and `ModuleMismatch` all
around. I am wondering if we can check it by inserting a check in
`ASTReader::ReadControlBlock` in `case IMPORT:` where we can check the
`ImportedName` and the name stored i
@@ -1392,6 +1392,20 @@ class ASTReader
llvm::DenseMap DefinitionSource;
+ /// The set of extra flags about declarations that we have read from
+ /// the module file.
+ struct ExternalDeclarationBits {
+/// Indicates if given function declaration was a definition but
https://github.com/ChuanqiXu9 approved this pull request.
LGTM. Thanks.
https://github.com/llvm/llvm-project/pull/133500
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 commented:
LGTM. I'll leave the formal approval to @efriedma-quic
https://github.com/llvm/llvm-project/pull/133716
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cf
@@ -1390,7 +1390,19 @@ class ASTReader
/// predefines buffer may contain additional definitions.
std::string SuggestedPredefines;
- llvm::DenseMap DefinitionSource;
+ struct DefinitionSourceFlags {
+ExtKind HasExternalDefinitions : 2;
+
+/// Indicates if given fu
ChuanqiXu9 wrote:
> > > > > > While I may not able to look into them in detail recently, it may
> > > > > > be helpful to split this into seperate patches to review and to
> > > > > > land.
> > > > >
> > > > >
> > > > > I initially considered this, but @vgvassilev said in
> > > > > [root-pro
ChuanqiXu9 wrote:
LGTM generally.
Some other personal suggestion to the title, it might be better to add
`[modules]` to the title. Since my mail filter will highlight these mails with
the tag : ) This might be why I missed you last ping.
https://github.com/llvm/llvm-project/pull/132214
__
@@ -1390,7 +1390,19 @@ class ASTReader
/// predefines buffer may contain additional definitions.
std::string SuggestedPredefines;
- llvm::DenseMap DefinitionSource;
+ struct DefinitionSourceFlags {
+ExtKind HasExternalDefinitions : 2;
+
+/// Indicates if given fu
@@ -1390,7 +1390,19 @@ class ASTReader
/// predefines buffer may contain additional definitions.
std::string SuggestedPredefines;
- llvm::DenseMap DefinitionSource;
+ struct DefinitionSourceFlags {
ChuanqiXu9 wrote:
```suggestion
struct DefinitionSour
ChuanqiXu9 wrote:
> > > > While I may not able to look into them in detail recently, it may be
> > > > helpful to split this into seperate patches to review and to land.
> > >
> > >
> > > I initially considered this, but @vgvassilev said in
> > > [root-project/root#17722
> > > (comment)](htt
ChuanqiXu9 wrote:
> > Maybe you can test it with this and land it with different patches. So that
> > we can revert one of them if either of them are problematic but other parts
> > are fine.
>
> I'm ok with pushing the commits one-by-one after the PR is reviewed, just let
> me know.
>
> > >
Author: Chuanqi Xu
Date: 2025-03-27T14:04:41+08:00
New Revision: 80f216db530eda98a444bc1994c7d69a7107c3c6
URL:
https://github.com/llvm/llvm-project/commit/80f216db530eda98a444bc1994c7d69a7107c3c6
DIFF:
https://github.com/llvm/llvm-project/commit/80f216db530eda98a444bc1994c7d69a7107c3c6.diff
LO
ChuanqiXu9 wrote:
> Complete only needed partial specializations: It is unclear (to me) why this
> needs to be done "for safety", but this change significantly improves the
> effectiveness of lazy loading.
This comes from the logic: if we have a partial template specialization `A` and we need
ChuanqiXu9 wrote:
> > While I may not able to look into them in detail recently, it may be
> > helpful to split this into seperate patches to review and to land.
>
> I initially considered this, but @vgvassilev said in [root-project/root#17722
> (comment)](https://github.com/root-project/root/
Author: Chuanqi Xu
Date: 2025-03-26T16:01:08+08:00
New Revision: c41926013fd8b23c3d1eca51804a2de36c88433a
URL:
https://github.com/llvm/llvm-project/commit/c41926013fd8b23c3d1eca51804a2de36c88433a
DIFF:
https://github.com/llvm/llvm-project/commit/c41926013fd8b23c3d1eca51804a2de36c88433a.diff
LO
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/132802
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 approved this pull request.
https://github.com/llvm/llvm-project/pull/132802
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -9615,7 +9615,7 @@ ModuleFile *ASTReader::getLocalModuleFile(ModuleFile &M,
unsigned ID) const {
// It's a prefix (preamble, PCH, ...). Look it up by index.
unsigned IndexFromEnd = ID >> 1;
assert(IndexFromEnd && "got reference to unknown module file");
-ret
https://github.com/ChuanqiXu9 approved this pull request.
https://github.com/llvm/llvm-project/pull/131987
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/131591
Support the trivial "header"/source switch for module interfaces.
I initially thought the naming are bad and we should rename it. But later I
feel it is better to split patches as much as possible.
>From t
Author: Chuanqi Xu
Date: 2025-03-13T15:04:06+08:00
New Revision: 6345b009c3e58a6cd0eca835d5a935f8784cfda6
URL:
https://github.com/llvm/llvm-project/commit/6345b009c3e58a6cd0eca835d5a935f8784cfda6
DIFF:
https://github.com/llvm/llvm-project/commit/6345b009c3e58a6cd0eca835d5a935f8784cfda6.diff
LO
https://github.com/ChuanqiXu9 approved this pull request.
https://github.com/llvm/llvm-project/pull/130712
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Chuanqi Xu
Date: 2025-03-13T11:02:57+08:00
New Revision: 4d8070e9560269494654bd21a2b0c342f4bdae48
URL:
https://github.com/llvm/llvm-project/commit/4d8070e9560269494654bd21a2b0c342f4bdae48
DIFF:
https://github.com/llvm/llvm-project/commit/4d8070e9560269494654bd21a2b0c342f4bdae48.diff
LO
https://github.com/ChuanqiXu9 commented:
The patch itself seems not bad. But we prefer to ask for a test for such
changes.
https://github.com/llvm/llvm-project/pull/130712
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/
https://github.com/ChuanqiXu9 commented:
I am still concerning about the potential performance loss on using the
intrinsic on parameters. Did you have any insight?
https://github.com/llvm/llvm-project/pull/129255
___
cfe-commits mailing list
cfe-commi
@@ -9180,6 +9180,12 @@ bool Sema::hasAcceptableDefinition(NamedDecl *D,
NamedDecl **Suggested,
if (!getLangOpts().Modules && !getLangOpts().ModulesLocalVisibility)
return true;
+ // The external source may have additional definitions of this entity that
are
+ // visi
@@ -9180,6 +9180,12 @@ bool Sema::hasAcceptableDefinition(NamedDecl *D,
NamedDecl **Suggested,
if (!getLangOpts().Modules && !getLangOpts().ModulesLocalVisibility)
return true;
+ // The external source may have additional definitions of this entity that
are
+ // visi
@@ -9180,6 +9180,12 @@ bool Sema::hasAcceptableDefinition(NamedDecl *D,
NamedDecl **Suggested,
if (!getLangOpts().Modules && !getLangOpts().ModulesLocalVisibility)
return true;
+ // The external source may have additional definitions of this entity that
are
+ // visi
@@ -9180,6 +9180,12 @@ bool Sema::hasAcceptableDefinition(NamedDecl *D,
NamedDecl **Suggested,
if (!getLangOpts().Modules && !getLangOpts().ModulesLocalVisibility)
return true;
+ // The external source may have additional definitions of this entity that
are
+ // visi
@@ -9180,6 +9180,12 @@ bool Sema::hasAcceptableDefinition(NamedDecl *D,
NamedDecl **Suggested,
if (!getLangOpts().Modules && !getLangOpts().ModulesLocalVisibility)
return true;
+ // The external source may have additional definitions of this entity that
are
+ // visi
@@ -9180,6 +9180,12 @@ bool Sema::hasAcceptableDefinition(NamedDecl *D,
NamedDecl **Suggested,
if (!getLangOpts().Modules && !getLangOpts().ModulesLocalVisibility)
return true;
+ // The external source may have additional definitions of this entity that
are
+ // visi
@@ -10178,12 +10178,12 @@ void ASTReader::visitTopLevelModuleMaps(
}
void ASTReader::finishPendingActions() {
- while (
- !PendingIdentifierInfos.empty() || !PendingDeducedFunctionTypes.empty()
||
- !PendingDeducedVarTypes.empty() || !PendingIncompleteDeclChains.em
@@ -9180,6 +9180,12 @@ bool Sema::hasAcceptableDefinition(NamedDecl *D,
NamedDecl **Suggested,
if (!getLangOpts().Modules && !getLangOpts().ModulesLocalVisibility)
return true;
+ // The external source may have additional definitions of this entity that
are
+ // visi
@@ -10178,12 +10178,12 @@ void ASTReader::visitTopLevelModuleMaps(
}
void ASTReader::finishPendingActions() {
- while (
- !PendingIdentifierInfos.empty() || !PendingDeducedFunctionTypes.empty()
||
- !PendingDeducedVarTypes.empty() || !PendingIncompleteDeclChains.em
Author: Chuanqi Xu
Date: 2025-03-05T19:05:49+08:00
New Revision: ea15e8b16eacdf2fb3a9715c5fc753b62fdfd516
URL:
https://github.com/llvm/llvm-project/commit/ea15e8b16eacdf2fb3a9715c5fc753b62fdfd516
DIFF:
https://github.com/llvm/llvm-project/commit/ea15e8b16eacdf2fb3a9715c5fc753b62fdfd516.diff
LO
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/129212
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/129212
>From 8876ef70a08f8547d49b89275a3b1b455221abd0 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Fri, 28 Feb 2025 17:03:49 +0800
Subject: [PATCH 1/3] [C++20] [Modules] Support generating in-class defined
funct
ChuanqiXu9 wrote:
> > > Thanks, LGTM.
> > > With just a little more effort you could add the EOF stuff in there too.
> >
> >
> > What do you mean by EOF stuff?
>
> It seems you can deduplicate by moving this block into the scope guard:
>
> ```c++
> while (Tok.isNot(tok::eof))
>
ChuanqiXu9 wrote:
> > Since the case a coroutine without a suspend point is relatively rare case
> > to me.
>
> For what it's worth, this issue isn't limited to coroutines without any
> suspend point. It can also occur:
>
> * If the coroutine conditionally doesn't await (e.g., `if (condition)
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/129212
See the example:
```
export module func;
class C {
public:
void member() try {
} catch (...) {
}
};
```
We woudln't generate the definition for `C::member` but we should. Since the
function i
Author: Chuanqi Xu
Date: 2025-02-28T16:03:50+08:00
New Revision: 15c49b9db3f60bdbd320271d5e97f118c00b95dd
URL:
https://github.com/llvm/llvm-project/commit/15c49b9db3f60bdbd320271d5e97f118c00b95dd
DIFF:
https://github.com/llvm/llvm-project/commit/15c49b9db3f60bdbd320271d5e97f118c00b95dd.diff
LO
ChuanqiXu9 wrote:
> Even for a real suspend, though, isn't it still possible for the coroutine to
> be resumed on a different thread, completed, and the frame deleted, all
> before the coroutine ramp finishes executing on the current thread?
Technically possible, you got me.
https://github.co
Author: Chuanqi Xu
Date: 2025-02-28T13:36:29+08:00
New Revision: 170b5736824bd4f70a7bf9dd0028b997d85ba76f
URL:
https://github.com/llvm/llvm-project/commit/170b5736824bd4f70a7bf9dd0028b997d85ba76f
DIFF:
https://github.com/llvm/llvm-project/commit/170b5736824bd4f70a7bf9dd0028b997d85ba76f.diff
LO
https://github.com/ChuanqiXu9 approved this pull request.
Abstractly the current one looks good to stop the bleeding first.
But for the issue itself, I still feel we can fix it in the middle end. Since
the case a coroutine without a suspend point is relatively rare case to me.
https://github.c
Author: Chuanqi Xu
Date: 2025-02-27T18:51:39+08:00
New Revision: e3f52690c796baca241a6771d897adc6670a1ed8
URL:
https://github.com/llvm/llvm-project/commit/e3f52690c796baca241a6771d897adc6670a1ed8
DIFF:
https://github.com/llvm/llvm-project/commit/e3f52690c796baca241a6771d897adc6670a1ed8.diff
LO
ChuanqiXu9 wrote:
/cherry-pick
https://github.com/llvm/llvm-project/commit/ae839b02504a68a0dfe63ac8ec314d9d7a6ce8df
https://github.com/llvm/llvm-project/pull/125988
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi
ChuanqiXu9 wrote:
I hope to backport this to 20.x. It shouldn't be riskful given the modules
support in clangd is controlled by an "experiment" option.
https://github.com/llvm/llvm-project/pull/125988
___
cfe-commits mailing list
cfe-commits@lists.llv
https://github.com/ChuanqiXu9 milestoned
https://github.com/llvm/llvm-project/pull/125988
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/125988
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -6097,10 +6097,29 @@ const char *Driver::GetNamedOutputPath(Compilation &C,
const JobAction &JA,
}
llvm::PrettyStackTraceString CrashInfo("Computing output path");
+
// Output to a user requested destination?
if (AtTopLevel && !isa(JA) && !isa(JA)) {
-if (Arg
Author: Chuanqi Xu
Date: 2025-02-25T13:30:30+08:00
New Revision: 366daddfad9aa38ebb7d40055cf65f4ecb7dd6f9
URL:
https://github.com/llvm/llvm-project/commit/366daddfad9aa38ebb7d40055cf65f4ecb7dd6f9
DIFF:
https://github.com/llvm/llvm-project/commit/366daddfad9aa38ebb7d40055cf65f4ecb7dd6f9.diff
LO
ChuanqiXu9 wrote:
> > In the issue (#127499) you pointed out that this issue applies to the MSVC
> > ABI where all parameters are destroyed in the callee. Is it reasonable to
> > construct the analogous test case in that environment?
>
> Yes, in fact the reproducer on that issue will trigger u
https://github.com/ChuanqiXu9 approved this pull request.
https://github.com/llvm/llvm-project/pull/128103
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Chuanqi Xu
Date: 2025-02-21T10:48:30+08:00
New Revision: 24c06a19be7bcf28b37e5eabbe65df95a2c0265a
URL:
https://github.com/llvm/llvm-project/commit/24c06a19be7bcf28b37e5eabbe65df95a2c0265a
DIFF:
https://github.com/llvm/llvm-project/commit/24c06a19be7bcf28b37e5eabbe65df95a2c0265a.diff
LO
ChuanqiXu9 wrote:
> > Adding metadata to an instruction should never be required for correctness
>
> I figured the existing use and the fact that it only needs to survive until
> CoroSplit made it good enough. But you're right, we should do better.
>
> I do think we need an explicit way to tel
https://github.com/ChuanqiXu9 commented:
would you like to add a test?
https://github.com/llvm/llvm-project/pull/128103
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1104,9 +1104,13 @@ void Sema::ActOnStartOfTranslationUnit() {
}
void Sema::ActOnEndOfTranslationUnitFragment(TUFragmentKind Kind) {
- // No explicit actions are required at the end of the global module fragment.
- if (Kind == TUFragmentKind::Global)
+ if (Kind == TUFrag
@@ -1104,9 +1104,13 @@ void Sema::ActOnStartOfTranslationUnit() {
}
void Sema::ActOnEndOfTranslationUnitFragment(TUFragmentKind Kind) {
- // No explicit actions are required at the end of the global module fragment.
- if (Kind == TUFragmentKind::Global)
+ if (Kind == TUFrag
1 - 100 of 1836 matches
Mail list logo
