Sirraide wrote:
It seems that a parameter to `getAddress()` that wasn’t being used has been
removed, which caused builds to break after I merged this. My bad; I’ve already
pushed a fix for this: #93086. I didn’t wait for CI this time because it was
passing before (except for an unrelated
@@ -4693,6 +4694,17 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
@@ -4693,6 +4694,17 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
@@ -4693,6 +4694,17 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
@@ -4693,6 +4694,17 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
https://github.com/Sirraide closed
https://github.com/llvm/llvm-project/pull/89828
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Sirraide wrote:
> Should I just run make_cxx_dr_status again then and commit the result?
I ended up figuring it out after talking to @Endilll about it.
Also, the only CI failure earlier was something unrelated
(CoverageMapping/mcdc-system-headers.cpp).
https://github.com/Sirraide updated
https://github.com/llvm/llvm-project/pull/89828
>From b5422012a65165f27bb31be7e9490892f663acfe Mon Sep 17 00:00:00 2001
From: Sirraide
Date: Tue, 23 Apr 2024 22:45:29 +0200
Subject: [PATCH 1/6] [Clang] [CodeGen] Perform derived-to-base conversion on
Sirraide wrote:
> Endilll just updated the list of DRs to avoid unrelated changes, so by fixing
> the conflict, only changes to cwg2881 should be in your PR
Should I just run `make_cxx_dr_status` again then and commit the result?
https://github.com/llvm/llvm-project/pull/89828
https://github.com/cor3ntin approved this pull request.
I think this makes sense. Thanks!
@Endilll just updated the list of DRs to avoid unrelated changes, so by fixing
the conflict, only changes to cwg2881 should be in your PR
https://github.com/llvm/llvm-project/pull/89828
https://github.com/Sirraide updated
https://github.com/llvm/llvm-project/pull/89828
>From b5422012a65165f27bb31be7e9490892f663acfe Mon Sep 17 00:00:00 2001
From: Sirraide
Date: Tue, 23 Apr 2024 22:45:29 +0200
Subject: [PATCH 1/5] [Clang] [CodeGen] Perform derived-to-base conversion on
Sirraide wrote:
> You should run make_cxx_drs, otherwise I think this looks in good shape.
Will do.
> I think we should diag earlier (because if the lambda is not use we should
> still signal it's broken) but doing that as a follow up PR seems reasonable.
>
> Less redundant diags is better
cor3ntin wrote:
You should run make_cxx_drs, otherwise I think this looks in good shape.
I think we should diag earlier (because if the lambda is not use we should
still signal it's broken) but doing that as a follow up PR seems reasonable.
Less redundant diags is better but if we can't avoid
Sirraide wrote:
Ok, I’ve looked into this a bit more, and it seems that checking for this at
instantiation time ends up being more complicated and produces more diagnostics
than just checking it at the call site; I’ve added a comment about that.
Other than that, is there anything else that we
https://github.com/Sirraide updated
https://github.com/llvm/llvm-project/pull/89828
>From b5422012a65165f27bb31be7e9490892f663acfe Mon Sep 17 00:00:00 2001
From: Sirraide
Date: Tue, 23 Apr 2024 22:45:29 +0200
Subject: [PATCH 1/4] [Clang] [CodeGen] Perform derived-to-base conversion on
cor3ntin wrote:
> @cor3ntin There already was a FIXME to consider moving this check to where
> the call operator is first instantiated; should I look into that as well or
> is it fine to leave this here? Asking because I’m assuming there’s a reason
> why it wasn’t done that way.
If you can
Sirraide wrote:
@cor3ntin There already was a FIXME to consider moving this check to where the
call operator is first instantiated; should I look into that as well or is it
fine to leave this here? Asking because I’m assuming there’s a reason why it
wasn’t done that way.
https://github.com/Sirraide updated
https://github.com/llvm/llvm-project/pull/89828
>From b5422012a65165f27bb31be7e9490892f663acfe Mon Sep 17 00:00:00 2001
From: Sirraide
Date: Tue, 23 Apr 2024 22:45:29 +0200
Subject: [PATCH 1/3] [Clang] [CodeGen] Perform derived-to-base conversion on
Sirraide wrote:
> @Sirraide See example of
>
> https://github.com/llvm/llvm-project/blob/662ef8604268b207910225ecca90daf30a46720b/clang/test/CXX/drs/dr25xx.cpp#L148
>
>
> In this case, the date should be 2024-04-19.
Ah, thanks.
https://github.com/llvm/llvm-project/pull/89828
Endilll wrote:
@Sirraide See example of
https://github.com/llvm/llvm-project/blob/662ef8604268b207910225ecca90daf30a46720b/clang/test/CXX/drs/dr25xx.cpp#L148
In this case, the date should be 2024-04-19.
https://github.com/llvm/llvm-project/pull/89828
Sirraide wrote:
I’m also not sure if the `dr28xx.cpp` file is meant for open issues, but I’ve
put the tests for this there for now.
https://github.com/llvm/llvm-project/pull/89828
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
Sirraide wrote:
Ok, I’ve added a check for CWG 2881 to sema, but there’s at least 2 things I
still want to take a look at:
- [ ] Consider emitting the upcast once in the function prologue instead of
every time a variable is accessed.
- [ ] Check for invalid explicit object parameters when the
https://github.com/Sirraide updated
https://github.com/llvm/llvm-project/pull/89828
>From b5422012a65165f27bb31be7e9490892f663acfe Mon Sep 17 00:00:00 2001
From: Sirraide
Date: Tue, 23 Apr 2024 22:45:29 +0200
Subject: [PATCH 1/2] [Clang] [CodeGen] Perform derived-to-base conversion on
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
llvmbot wrote:
@llvm/pr-subscribers-clang-codegen
Author: None (Sirraide)
Changes
Consider this code:
```c++
template typename... Ts
struct Overloaded : Ts... { using Ts::operator()...; };
template typename... Ts
Overloaded(Ts...) - OverloadedTs...;
void f() {
int x;
Overloaded o {
https://github.com/Sirraide created
https://github.com/llvm/llvm-project/pull/89828
Consider this code:
```c++
template
struct Overloaded : Ts... { using Ts::operator()...; };
template
Overloaded(Ts...) -> Overloaded;
void f() {
int x;
Overloaded o {
[&](this auto& self) {
37 matches
Mail list logo
