@@ -79,6 +79,73 @@ using namespace llvm;
namespace {
+// Created on demand if the coro-early pass has work to do.
+class Lowerer : public coro::LowererBase {
+ IRBuilder<> Builder;
+ void lowerAwaitSuspend(CoroAwaitSuspendInst *CB);
+
+public:
+ Lowerer(Module &M) : Lowere
@@ -79,6 +79,73 @@ using namespace llvm;
namespace {
+// Created on demand if the coro-early pass has work to do.
+class Lowerer : public coro::LowererBase {
ChuanqiXu9 wrote:
Why do we need to inherit `coro::LowererBase`? Can't we make it directly in a
fun
@@ -338,6 +386,85 @@ static QualType getCoroutineSuspendExprReturnType(const
ASTContext &Ctx,
}
#endif
+llvm::Function *CodeGenFunction::generateAwaitSuspendHelper(
ChuanqiXu9 wrote:
For such function definitions, generally we need a comment about its reason
@@ -79,6 +79,73 @@ using namespace llvm;
namespace {
+// Created on demand if the coro-early pass has work to do.
+class Lowerer : public coro::LowererBase {
+ IRBuilder<> Builder;
+ void lowerAwaitSuspend(CoroAwaitSuspendInst *CB);
+
+public:
+ Lowerer(Module &M) : Lowere
@@ -232,16 +237,59 @@ static LValueOrRValue
emitSuspendExpression(CodeGenFunction &CGF, CGCoroData &Co
auto *NullPtr = llvm::ConstantPointerNull::get(CGF.CGM.Int8PtrTy);
auto *SaveCall = Builder.CreateCall(CoroSave, {NullPtr});
- CGF.CurCoro.InSuspendBlock = true;
- aut
@@ -1744,6 +1744,273 @@ a call to ``llvm.coro.suspend.retcon`` after resuming
abnormally.
In a yield-once coroutine, it is undefined behavior if the coroutine
executes a call to ``llvm.coro.suspend.retcon`` after resuming in any way.
+.. _coro.await.suspend:
+
+'llvm.coro.awa
@@ -1744,6 +1744,273 @@ a call to ``llvm.coro.suspend.retcon`` after resuming
abnormally.
In a yield-once coroutine, it is undefined behavior if the coroutine
executes a call to ``llvm.coro.suspend.retcon`` after resuming in any way.
+.. _coro.await.suspend:
+
+'llvm.coro.awa
@@ -232,16 +237,59 @@ static LValueOrRValue
emitSuspendExpression(CodeGenFunction &CGF, CGCoroData &Co
auto *NullPtr = llvm::ConstantPointerNull::get(CGF.CGM.Int8PtrTy);
auto *SaveCall = Builder.CreateCall(CoroSave, {NullPtr});
- CGF.CurCoro.InSuspendBlock = true;
- aut
@@ -1744,6 +1744,273 @@ a call to ``llvm.coro.suspend.retcon`` after resuming
abnormally.
In a yield-once coroutine, it is undefined behavior if the coroutine
executes a call to ``llvm.coro.suspend.retcon`` after resuming in any way.
+.. _coro.await.suspend:
+
+'llvm.coro.awa
@@ -79,6 +79,73 @@ using namespace llvm;
namespace {
+// Created on demand if the coro-early pass has work to do.
+class Lowerer : public coro::LowererBase {
+ IRBuilder<> Builder;
+ void lowerAwaitSuspend(CoroAwaitSuspendInst *CB);
+
+public:
+ Lowerer(Module &M) : Lowere
@@ -5036,14 +5036,17 @@ class CoroutineSuspendExpr : public Expr {
Stmt *SubExprs[SubExpr::Count];
OpaqueValueExpr *OpaqueValue = nullptr;
+ OpaqueValueExpr *OpaqueFramePtr = nullptr;
ChuanqiXu9 wrote:
I still think we can get rid of storing `OpaqueFrame
@@ -232,16 +237,59 @@ static LValueOrRValue
emitSuspendExpression(CodeGenFunction &CGF, CGCoroData &Co
auto *NullPtr = llvm::ConstantPointerNull::get(CGF.CGM.Int8PtrTy);
auto *SaveCall = Builder.CreateCall(CoroSave, {NullPtr});
- CGF.CurCoro.InSuspendBlock = true;
- aut
@@ -173,6 +173,10 @@ static bool ResumeStmtCanThrow(const Stmt *S) {
return false;
}
+static bool AwaitSuspendStmtCanThrow(const Stmt *S) {
+ return ResumeStmtCanThrow(S);
+}
ChuanqiXu9 wrote:
Maybe it will be better to rename `ResumeStmtCanThrow` to `Stmt
https://github.com/ChuanqiXu9 commented:
I got the reason why I felt `__await_suspend_helper_` was odd. In my
imagination, we only need to emit the function `await_suspend(handle)` to an
LLVM function and pass that to `llvm.coro.await.suspend` directly.
https://github.com/llvm/llvm-project/pul
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
ChuanqiXu9 wrote:
> I'd still idly vote against adding this flag/support - but if other modules
> contributors feel it's the right thing to do, I won't stand in the way.
Yeah, as @mizvekov said, this is intended to be a transparent change to users.
(unless the users are testing volunteers, whi
@@ -457,6 +457,28 @@ Note that **currently** the compiler doesn't consider
inconsistent macro definit
Currently Clang would accept the above example. But it may produce surprising
results if the
debugging code depends on consistent use of ``NDEBUG`` also in other
translation
@@ -457,6 +457,28 @@ Note that **currently** the compiler doesn't consider
inconsistent macro definit
Currently Clang would accept the above example. But it may produce surprising
results if the
debugging code depends on consistent use of ``NDEBUG`` also in other
translation
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/79959
>From beb1a4b89f941f41a6e220447dcda6d6fc231a0b Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Tue, 30 Jan 2024 15:57:35 +0800
Subject: [PATCH 1/2] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf
Close ht
@@ -0,0 +1,31 @@
+// UNSUPPORTED: system-aix
+//
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+//
+// RUN: %clang -std=c++20 %t/mod.cppm --precompile \
+// RUN: -o %t/mod.pcm
+// RUN: %clang %t/mod.pcm -c -o %t/mod.o
+// RUN: %clang -shared %t/mod.o -o %t/
@@ -0,0 +1,31 @@
+// UNSUPPORTED: system-aix
+//
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+//
+// RUN: %clang -std=c++20 %t/mod.cppm --precompile \
+// RUN: -o %t/mod.pcm
+// RUN: %clang %t/mod.pcm -c -o %t/mod.o
+// RUN: %clang -shared %t/mod.o -o %t/
https://github.com/ChuanqiXu9 commented:
This is what I had in mind
https://github.com/llvm/llvm-project/pull/79261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/79261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/75545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 approved this pull request.
LGTM then.
https://github.com/llvm/llvm-project/pull/75545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
> with stack exhaustion warning, the compiler can continue (albeit being slow
> or unstable). The depth limit here will be a hard restriction and so there
> will be no workaround if the code reaches it.
It is a surprise to me that this is only a warning instead of a hard erro
ChuanqiXu9 wrote:
> I am not saying it's a bad idea to add this for testing purposes, but given
> how fragile this approach is, I think we should not provide configuration
> knobs to users there. At least everyone sees crashes at roughly the same
> points right now (although variation is still
@@ -4099,7 +4099,9 @@ Decl *ASTReader::ReadDeclRecord(DeclID ID) {
// calls to Decl::getASTContext() by Decl's methods will find the
// TranslationUnitDecl without crashing.
D->setDeclContext(Context.getTranslationUnitDecl());
- Reader.Visit(D);
+
+ // Reading some decl
ChuanqiXu9 wrote:
> > > IncrementalExtensions
> >
> >
> > But the change itself is to make `IncrementalExtensions` a compatible lang
> > options. So that we don't need to specify it when generating the modules.
>
> I mean conditionally if `IncrementalExtensions` is set we change the target
>
ChuanqiXu9 wrote:
I am wondering if it helps if we specify the target triple in the test, then it
won't be so troublesome.
https://github.com/llvm/llvm-project/pull/79261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
ChuanqiXu9 wrote:
> IncrementalExtensions
But the change itself is to make `IncrementalExtensions` a compatible lang
options. So that we don't need to specify it when generating the modules.
https://github.com/llvm/llvm-project/pull/79261
___
cfe-com
ChuanqiXu9 wrote:
> > > > > As far as I can tell from [#76774
> > > > > (comment)](https://github.com/llvm/llvm-project/pull/76774#issuecomment-1914177330)
> > > > > above, the last push only changed the default value of
> > > > > `LoadExternalSpecializationsLazily`. In that case, my test resu
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/79959
>From beb1a4b89f941f41a6e220447dcda6d6fc231a0b Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Tue, 30 Jan 2024 15:57:35 +0800
Subject: [PATCH] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf
Close https:
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/79959
Close https://github.com/llvm/llvm-project/issues/79240
Cite the comment from @mizvekov in
//github.com/llvm/llvm-project/issues/79240:
> There are two kinds of bugs / issues relevant here:
>
> Clang bugs tha
ChuanqiXu9 wrote:
Another idea is to limit (or check) the threshold for
`ASTReader::NumCurrentElementsDeserializing`. Then we still can print the stack
trace by some utils in LLVM also we can get better performance than this.
https://github.com/llvm/llvm-project/pull/79875
___
@@ -0,0 +1,43 @@
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/usings.cppm -o
%t/usings.pcm
+// RUN: %clang_cc1 -std=c++20 -fmodule-file=usings=%t/usings.pcm %t/use.cpp
-verify -fsyntax-only -Wno-stac
https://github.com/ChuanqiXu9 commented:
To make this testable, maybe we can refactor
`clang::runWithSufficientStackSpace` a little bit to make `DesiredStackSize`
and `isStackNearlyExhausted::SufficientStack` configurable.
https://github.com/llvm/llvm-project/pull/79875
__
@@ -4099,7 +4099,9 @@ Decl *ASTReader::ReadDeclRecord(DeclID ID) {
// calls to Decl::getASTContext() by Decl's methods will find the
// TranslationUnitDecl without crashing.
D->setDeclContext(Context.getTranslationUnitDecl());
- Reader.Visit(D);
+
+ // Reading some decl
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/79875
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
> > > As far as I can tell from [#76774
> > > (comment)](https://github.com/llvm/llvm-project/pull/76774#issuecomment-1914177330)
> > > above, the last push only changed the default value of
> > > `LoadExternalSpecializationsLazily`. In that case, my test results from
> > >
https://github.com/ChuanqiXu9 commented:
Thanks for looking into this. I haven't looked it in details. Given this is
complex, it should take a relative longer time.
Here is some quick feedbacks:
- Every time we change the non-static data members of AST nodes, we need to
update the serializatio
ChuanqiXu9 wrote:
> As far as I can tell from [#76774
> (comment)](https://github.com/llvm/llvm-project/pull/76774#issuecomment-1914177330)
> above, the last push only changed the default value of
> `LoadExternalSpecializationsLazily`. In that case, my test results from
> [#76774
> (comment)
ChuanqiXu9 wrote:
> The newest version of this patch still doesn't work correctly. Switching the
> new `LoadExternalSpecializationsLazily` to disabled by default (somehow the
> argument didn't work on its own) instead crashes, most of the cases involving
> `MultiOnDiskHashTable`. I suspect som
Author: Chuanqi Xu
Date: 2024-01-29T14:35:23+08:00
New Revision: 4118082f651a05cca258c684ab1199578b57afac
URL:
https://github.com/llvm/llvm-project/commit/4118082f651a05cca258c684ab1199578b57afac
DIFF:
https://github.com/llvm/llvm-project/commit/4118082f651a05cca258c684ab1199578b57afac.diff
LO
Author: Chuanqi Xu
Date: 2024-01-29T11:44:59+08:00
New Revision: a0b6747804e46665ecfd00295b60432bfe1775b6
URL:
https://github.com/llvm/llvm-project/commit/a0b6747804e46665ecfd00295b60432bfe1775b6
DIFF:
https://github.com/llvm/llvm-project/commit/a0b6747804e46665ecfd00295b60432bfe1775b6.diff
LO
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/75545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -728,7 +728,7 @@ getCompilationDataBase(int argc, char **argv, std::string
&ErrorMessage) {
*Diags);
std::unique_ptr C(
TheDriver.BuildCompilation(CommandLine));
- if (!C)
+ if (C->getJobs().empty())
ChuanqiXu9 wrote:
`
https://github.com/ChuanqiXu9 commented:
It will be better to have a test for this.
https://github.com/llvm/llvm-project/pull/75545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/75912
>From 7a5c4ccd37b263a4d3d01df16591b576a64e839f Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Tue, 19 Dec 2023 17:00:59 +0800
Subject: [PATCH] [C++20] [Modules] [Itanium ABI] Generate the vtable in the
modul
@@ -1046,6 +1046,15 @@ CodeGenModule::getVTableLinkage(const CXXRecordDecl *RD)
{
if (!RD->isExternallyVisible())
return llvm::GlobalVariable::InternalLinkage;
+ // Previously we'll decide the linkage of the vtable by the linkage
+ // of the key function. But within m
@@ -1801,6 +1801,12 @@ void ItaniumCXXABI::emitVTableDefinitions(CodeGenVTables
&CGVT,
if (VTable->hasInitializer())
return;
+ // If the class are attached to a C++ named module other than the one
ChuanqiXu9 wrote:
Done
https://github.com/llvm/llvm-p
@@ -0,0 +1,50 @@
+// REQUIRES: !system-windows
+
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+//
+// RUN: %clang_cc1 -std=c++20 %t/layer1.cppm -triple %itanium_abi_triple \
+// RUN: -emit-module-interface -o %t/foo-layer1.pcm
+// RUN: %clang_cc1 -std=c++20 %t/l
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/75912
>From 630e59738990c3dd570065b8b7a050d822d68df0 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Tue, 19 Dec 2023 17:00:59 +0800
Subject: [PATCH] [C++20] [Modules] [Itanium ABI] Generate the vtable in the
modul
ChuanqiXu9 wrote:
It looks true but the test does the same thing as other tests to build modules
https://github.com/llvm/llvm-project/pull/79261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe
ChuanqiXu9 wrote:
> For what it's worth, this test appears to fail when
> `LLVM_DEFAULT_TARGET_TRIPLE` is changed (my script sets it to the output of
> my Linux distribution's `clang -print-target-triple`)
>
> ```
> error: PCH file was compiled for the target 'x86_64-pc-linux-gnu' but the
> c
https://github.com/ChuanqiXu9 approved this pull request.
LGTM. Sorry for forgetting testing lldb : (
https://github.com/llvm/llvm-project/pull/79396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
Author: Chuanqi Xu
Date: 2024-01-24T16:14:14+08:00
New Revision: bae1adae1c7cdf3b0bd618fc9cd5af251dc901ed
URL:
https://github.com/llvm/llvm-project/commit/bae1adae1c7cdf3b0bd618fc9cd5af251dc901ed
DIFF:
https://github.com/llvm/llvm-project/commit/bae1adae1c7cdf3b0bd618fc9cd5af251dc901ed.diff
LO
Author: Chuanqi Xu
Date: 2024-01-24T16:10:49+08:00
New Revision: c1259650e742e7b3053f6520729b4c1f44c27814
URL:
https://github.com/llvm/llvm-project/commit/c1259650e742e7b3053f6520729b4c1f44c27814
DIFF:
https://github.com/llvm/llvm-project/commit/c1259650e742e7b3053f6520729b4c1f44c27814.diff
LO
ChuanqiXu9 wrote:
> Hi @ChuanqiXu9, the test you added is failing on the PS4 bot because for the
> PS4 target, it requires an external linker which is not present/available.
> Can the test be rewritten to not require linking?
>
> https://lab.llvm.org/buildbot/#/builders/139/builds/57928
>
> `
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/79261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/79261
This comes from when I playing around clang-repl with moduels : )
I succeeded to import std with https://libcxx.llvm.org/Modules.html and calling
`std::printf` after this patch.
I want to put the documentati
@@ -1458,7 +1458,7 @@ bool HeaderSearch::ShouldEnterIncludeFile(Preprocessor
&PP,
} else {
// Otherwise, if this is a #include of a file that was previously #import'd
// or if this is the second #include of a #pragma once file, ignore it.
-if ((FileInfo.isPragmaO
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/76119
>From 65fdddbd501b36f7dcef2db3fd25a7a4a1f80a0b Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Thu, 21 Dec 2023 11:24:14 +0800
Subject: [PATCH] [Modules] [HeaderSearch] Don't reenter headers if it is
pragma o
Author: Chuanqi Xu
Date: 2024-01-23T16:19:51+08:00
New Revision: ba1e84fb8f45e102f40f409fcfe9b420fbf9fb70
URL:
https://github.com/llvm/llvm-project/commit/ba1e84fb8f45e102f40f409fcfe9b420fbf9fb70
DIFF:
https://github.com/llvm/llvm-project/commit/ba1e84fb8f45e102f40f409fcfe9b420fbf9fb70.diff
LO
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/76774
>From 26bd7dc5139811b2b0d8d8642a67b67340eeb1d5 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 3 Jan 2024 11:33:17 +0800
Subject: [PATCH 1/4] Load Specializations Lazily
---
clang/include/clang/AST/Decl
ChuanqiXu9 wrote:
In the newest push, I changed 2 things:
- In `ASTReader::LoadExternalSpecializations`, I am moving `Deserializing
LookupResults(this);` before calculating the ODR hash for template arguments.
Since I didn't realize that the ODRHash may trigger deserializing before.
- I introdu
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/76774
>From 26bd7dc5139811b2b0d8d8642a67b67340eeb1d5 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 3 Jan 2024 11:33:17 +0800
Subject: [PATCH 1/4] Load Specializations Lazily
---
clang/include/clang/AST/Decl
ChuanqiXu9 wrote:
> > > > I tried applying this patch to ROOT/Cling and it fails to build because
> > > > something is of the opinion that `std::is_integral::value` is not
> > > > true. I don't have time right now to investigate further, but since
> > > > this is the only change I did it is hi
Author: Chuanqi Xu
Date: 2024-01-22T14:24:33+08:00
New Revision: a31a60074717fc40887cfe132b77eec93bedd307
URL:
https://github.com/llvm/llvm-project/commit/a31a60074717fc40887cfe132b77eec93bedd307
DIFF:
https://github.com/llvm/llvm-project/commit/a31a60074717fc40887cfe132b77eec93bedd307.diff
LO
ChuanqiXu9 wrote:
> > I tried applying this patch to ROOT/Cling and it fails to build because
> > something is of the opinion that `std::is_integral::value` is not
> > true. I don't have time right now to investigate further, but since this is
> > the only change I did it is highly likely that
@@ -3924,6 +3925,154 @@ class ASTDeclContextNameLookupTrait {
} // namespace
+namespace {
+class SpecializationsLookupTrait {
+ ASTWriter &Writer;
+ llvm::SmallVector DeclIDs;
+
+public:
+ using key_type = unsigned;
+ using key_type_ref = key_type;
+
+ /// A start and en
Author: Chuanqi Xu
Date: 2024-01-19T15:26:22+08:00
New Revision: 407db48eb4d387ae272bfbef9b12868806f1e830
URL:
https://github.com/llvm/llvm-project/commit/407db48eb4d387ae272bfbef9b12868806f1e830
DIFF:
https://github.com/llvm/llvm-project/commit/407db48eb4d387ae272bfbef9b12868806f1e830.diff
LO
ChuanqiXu9 wrote:
> We saw some failures internally with this patch:
>
> * `"'absl::AnyInvocable' has different definitions in different
> modules;".`
> Probably related to the template arguments stability you mention.
> * `"No type named 'MemberType' in 'some_object::Traits'"`.
> I suspect
https://github.com/ChuanqiXu9 approved this pull request.
LGTM. Thanks.
https://github.com/llvm/llvm-project/pull/78589
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Chuanqi Xu
Date: 2024-01-18T17:09:35+08:00
New Revision: 085eae6b863881fb9fda323e5b672b04a00ed19e
URL:
https://github.com/llvm/llvm-project/commit/085eae6b863881fb9fda323e5b672b04a00ed19e
DIFF:
https://github.com/llvm/llvm-project/commit/085eae6b863881fb9fda323e5b672b04a00ed19e.diff
LO
@@ -11802,6 +11802,27 @@ static bool CheckMultiVersionFunction(Sema &S,
FunctionDecl *NewFD,
OldDecl, Previous);
}
+static void CheckFunctionDeclarationAttributesUsage(Sema &S,
+Funct
@@ -692,6 +692,13 @@ def warn_maybe_falloff_nonvoid_function : Warning<
def warn_falloff_nonvoid_function : Warning<
"non-void function does not return a value">,
InGroup;
+def warn_const_attr_with_pure_attr : Warning<
+ "'const' attribute imposes more restrictions, 'pure'
@@ -11802,6 +11802,27 @@ static bool CheckMultiVersionFunction(Sema &S,
FunctionDecl *NewFD,
OldDecl, Previous);
}
+static void CheckFunctionDeclarationAttributesUsage(Sema &S,
+Funct
https://github.com/ChuanqiXu9 approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/78200
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -692,6 +692,13 @@ def warn_maybe_falloff_nonvoid_function : Warning<
def warn_falloff_nonvoid_function : Warning<
"non-void function does not return a value">,
InGroup;
+def warn_const_attr_with_pure_attr : Warning<
+ "'const' attribute imposes more restrictions, 'pure'
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/78200
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
> > LGTM.
> > We need to delete
> > `clang/test/Driver/Inputs/cxx23_modules/usr/lib/x86_64-linux-gnu/libc++.so`
> > and
> > `clang/test/Driver/Inputs/cxx23_modules/usr/lib/x86_64-linux-gnu/modules.json`,
> > we should generate them with `split-file`
>
> Are you sure that is
https://github.com/ChuanqiXu9 approved this pull request.
LGTM then
https://github.com/llvm/llvm-project/pull/77066
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -15845,8 +15845,10 @@ void Sema::CheckCoroutineWrapper(FunctionDecl *FD) {
RecordDecl *RD = FD->getReturnType()->getAsRecordDecl();
if (!RD || !RD->getUnderlyingDecl()->hasAttr())
return;
- // Allow `get_return_object()`.
- if (FD->getDeclName().isIdentifier() &&
+
Author: Chuanqi Xu
Date: 2024-01-16T11:32:10+08:00
New Revision: 1b6c1a3bd73be4dd904230c637d65810cf3334cd
URL:
https://github.com/llvm/llvm-project/commit/1b6c1a3bd73be4dd904230c637d65810cf3334cd
DIFF:
https://github.com/llvm/llvm-project/commit/1b6c1a3bd73be4dd904230c637d65810cf3334cd.diff
LO
@@ -0,0 +1,28 @@
+// From https://github.com/llvm/llvm-project/issues/77953
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/a.cppm -o %t/a.pcm
+// RUN: %clang_cc1 -std=c++20 -fmodule-file=a=%t/a.pcm %t/b.
ChuanqiXu9 wrote:
> > @ilya-biryukov any chance you/your folks could test this change for
> > performance implications in google? It's especially helpful to CERN, but
> > the last iteration of this direction had some regressions that stalled out
> > progress on that version a few years ago, so
@@ -11889,6 +11889,13 @@ bool Sema::CheckFunctionDeclaration(Scope *S,
FunctionDecl *NewFD,
NewFD->setInvalidDecl();
}
+ if (NewFD->hasAttr() || NewFD->hasAttr()) {
+if (isa(NewFD))
+ Diag(NewFD->getLocation(), diag::warn_pure_attr_on_cxx_constructor);
+el
@@ -692,6 +692,13 @@ def warn_maybe_falloff_nonvoid_function : Warning<
def warn_falloff_nonvoid_function : Warning<
"non-void function does not return a value">,
InGroup;
+def warn_pure_attr_on_cxx_constructor : Warning<
+ "constructor cannot be 'pure' (undefined behavior
@@ -11889,6 +11889,13 @@ bool Sema::CheckFunctionDeclaration(Scope *S,
FunctionDecl *NewFD,
NewFD->setInvalidDecl();
}
+ if (NewFD->hasAttr() || NewFD->hasAttr()) {
+if (isa(NewFD))
+ Diag(NewFD->getLocation(), diag::warn_pure_attr_on_cxx_constructor);
+el
@@ -15845,8 +15845,10 @@ void Sema::CheckCoroutineWrapper(FunctionDecl *FD) {
RecordDecl *RD = FD->getReturnType()->getAsRecordDecl();
if (!RD || !RD->getUnderlyingDecl()->hasAttr())
return;
- // Allow `get_return_object()`.
- if (FD->getDeclName().isIdentifier() &&
+
@@ -7575,15 +7577,27 @@ static void
visitLifetimeBoundArguments(IndirectLocalPath &Path, Expr *Call,
Path.pop_back();
};
- if (ObjectArg && implicitObjectParamIsLifetimeBound(Callee))
-VisitLifetimeBoundArg(Callee, ObjectArg);
-
bool CheckCoroCall = false;
if
https://github.com/ChuanqiXu9 approved this pull request.
LGTM then.
https://github.com/llvm/llvm-project/pull/77465
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -15845,8 +15845,10 @@ void Sema::CheckCoroutineWrapper(FunctionDecl *FD) {
RecordDecl *RD = FD->getReturnType()->getAsRecordDecl();
if (!RD || !RD->getUnderlyingDecl()->hasAttr())
return;
- // Allow `get_return_object()`.
- if (FD->getDeclName().isIdentifier() &&
+
ChuanqiXu9 wrote:
@vsapsai gentle ping~
https://github.com/llvm/llvm-project/pull/76119
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Chuanqi Xu
Date: 2024-01-15T17:00:49+08:00
New Revision: 7bc170a261ae0daaddcc1abeacf7e9e0f1f66d02
URL:
https://github.com/llvm/llvm-project/commit/7bc170a261ae0daaddcc1abeacf7e9e0f1f66d02
DIFF:
https://github.com/llvm/llvm-project/commit/7bc170a261ae0daaddcc1abeacf7e9e0f1f66d02.diff
LO
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/76451
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/76451
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -33,6 +34,7 @@
#include "llvm/ADT/SmallString.h"
#include "llvm/ADT/SmallVector.h"
#include "llvm/ADT/StringExtras.h"
+#include "llvm/Support/Casting.h"
ChuanqiXu9 wrote:
Maybe we don't need this?
https://github.com/llvm/llvm-project/pull/77066
___
@@ -15845,8 +15845,10 @@ void Sema::CheckCoroutineWrapper(FunctionDecl *FD) {
RecordDecl *RD = FD->getReturnType()->getAsRecordDecl();
if (!RD || !RD->getUnderlyingDecl()->hasAttr())
return;
- // Allow `get_return_object()`.
- if (FD->getDeclName().isIdentifier() &&
+
1001 - 1100 of 1780 matches
Mail list logo