wzssyqa wrote:
@peterwaller-arm Ohh, there is so many `-none-unknown-` in current code. I
guess it may be widely used.
Do we really want to change all of them?
https://github.com/llvm/llvm-project/pull/89638
___
cfe-commits mailing list
cfe-commits@li
https://github.com/wzssyqa converted_to_draft
https://github.com/llvm/llvm-project/pull/89638
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jh7370 wrote:
> This looks like a nice improvement for folks using those generators. Even
> though most of these changes look straightforward, it would be a lot easier
> to review if this was broken up per subproject. Is there any reason that's
> not possible?
+1 to this: 195 files is too man
Author: Serge Pavlov
Date: 2024-04-23T14:14:02+07:00
New Revision: a04624206ddf03dc54d5c372e7eac13575b4124b
URL:
https://github.com/llvm/llvm-project/commit/a04624206ddf03dc54d5c372e7eac13575b4124b
DIFF:
https://github.com/llvm/llvm-project/commit/a04624206ddf03dc54d5c372e7eac13575b4124b.diff
https://github.com/spavloff closed
https://github.com/llvm/llvm-project/pull/85605
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/wzssyqa updated
https://github.com/llvm/llvm-project/pull/89638
>From 11ae27aeb512b661a3423a8b92642a9ec08ca6a1 Mon Sep 17 00:00:00 2001
From: YunQiang Su
Date: Tue, 23 Apr 2024 01:36:17 +0800
Subject: [PATCH] Triple::normalize: Set OS for 3-component triple with none as
midd
wzssyqa wrote:
@llvm/pr-subscribers-backend-arm @llvm/pr-subscribers-backend-aarch64
https://github.com/llvm/llvm-project/pull/89638
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zyn0217 updated
https://github.com/llvm/llvm-project/pull/89494
>From ba2e2a4bd2f7442003d6aa21f3d848cfef5061f6 Mon Sep 17 00:00:00 2001
From: Younan Zhang
Date: Sat, 20 Apr 2024 02:52:16 +0800
Subject: [PATCH] [Clang][Parser] Don't always destroy template annotations at
the
https://github.com/zyn0217 updated
https://github.com/llvm/llvm-project/pull/89494
>From 3d5d4d973b9a76d9a07cdd6b89b304e2c7f37308 Mon Sep 17 00:00:00 2001
From: Younan Zhang
Date: Sat, 20 Apr 2024 02:52:16 +0800
Subject: [PATCH] [Clang][Parser] Don't always destroy template annotations at
the
https://github.com/zwuis created https://github.com/llvm/llvm-project/pull/89713
clang don't check whether the operand of the & operator is enclosed in
parantheses when pointer to member is formed in unevaluated context, for
example:
```cpp
struct foo { int val; };
int main() { decltype(&(foo
Author: Daniel Grumberg
Date: 2024-04-23T09:00:08+01:00
New Revision: 05c1447b3eabe9cc4a27866094e46c57350c5d5a
URL:
https://github.com/llvm/llvm-project/commit/05c1447b3eabe9cc4a27866094e46c57350c5d5a
DIFF:
https://github.com/llvm/llvm-project/commit/05c1447b3eabe9cc4a27866094e46c57350c5d5a.dif
https://github.com/daniel-grumberg closed
https://github.com/llvm/llvm-project/pull/89277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
orcguru wrote:
> It looks like a few of the regression tests are failing on the
> reverse-iteration buildbot
> (https://lab.llvm.org/buildbot/#/builders/54/builds/9683)
Thank you! Posted: https://github.com/llvm/llvm-project/pull/89714
https://github.com/llvm/llvm-project/pull/66316
_
https://github.com/kito-cheng approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/89354
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hokein wrote:
> > > Regarding the __is_deducible type trait, GCC also provides one, but it
> > > was hidden from users and only used for internal CTAD implementation. I'm
> > > not sure if we should follow the same strategy in clang, ideas?
> >
> >
> > I have mixed feeling. What do you think
@@ -868,13 +868,7 @@ C++20 implementation status
Class template argument deduction for alias templates
https://wg21.link/p1814r0";>P1814R0
-
-
- Clang 19 (Partial)
- The associated constraints (over.match.class.deduct#3.3) for th
Author: NagyDonat
Date: 2024-04-23T10:20:34+02:00
New Revision: ce763bff081f8e97c7c3610ed0f15f14d60e875f
URL:
https://github.com/llvm/llvm-project/commit/ce763bff081f8e97c7c3610ed0f15f14d60e875f
DIFF:
https://github.com/llvm/llvm-project/commit/ce763bff081f8e97c7c3610ed0f15f14d60e875f.diff
LOG
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/89606
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1149,6 +1149,13 @@ std::string Triple::normalize(StringRef Str) {
}
}
+ // For 3-component triples, the middle component is used to set Vendor;
+ // while if it is "none", we'd prefer to set OS.
+ // This is for some baremetal cases, such as "arm-none-elf".
+ if
cor3ntin wrote:
> This approach is doable technically, but it feels hacky and fragile. What if
> we emit an error (or warning) diagnostic and reject the code when we parse
> the __is_deducible type trait?
Why do you think it is fragile? I think a comment around `BTT_IsDeducible`
would take ca
@@ -868,13 +868,7 @@ C++20 implementation status
Class template argument deduction for alias templates
https://wg21.link/p1814r0";>P1814R0
-
-
- Clang 19 (Partial)
- The associated constraints (over.match.class.deduct#3.3) for th
peterwaller-arm wrote:
I have tested building a toolchain using `aarch64-none-elf`, and the problems
described in my comment on
https://github.com/llvm/llvm-project/pull/89234#issuecomment-2069019606 are
resolved. The only change I had to make was to update some references to
`aarch64-none-el
Author: Chuanqi Xu
Date: 2024-04-23T16:56:14+08:00
New Revision: b8e3b2ad66cf78ad2b7832577b1d58dc93c5da21
URL:
https://github.com/llvm/llvm-project/commit/b8e3b2ad66cf78ad2b7832577b1d58dc93c5da21
DIFF:
https://github.com/llvm/llvm-project/commit/b8e3b2ad66cf78ad2b7832577b1d58dc93c5da21.diff
LO
cor3ntin wrote:
I should note that while i think this is correct per the standard, no one seems
to be conforming here
https://github.com/llvm/llvm-project/pull/89713
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi
DavidSpickett wrote:
> Ohh, there is so many -none-unknown- in current code. I guess it may be
> widely used. Do we really want to change all of them?
In current test cases, which were likely generated using clang. So they are
likely not relying on that exact form of the triple, it's just what
@@ -27,3 +26,20 @@ namespace rdar10544564 {
X (Y::*func_mem_ptr1)() = &Y::memfunc1;
X (Y::*func_mem_ptr2)() = &Y::memfunc2;
}
+
+namespace test2 {
+ struct A {
+int val;
+void func() {}
+ };
+
+ void test() {
+decltype(&(A::val)) ptr1; // expected-error {{inv
@@ -14644,6 +14644,17 @@ QualType Sema::CheckAddressOfOperand(ExprResult
&OrigOp, SourceLocation OpLoc) {
return QualType();
}
+ // C++11 [expr.unary.op] p4:
+ // A pointer to member is only formed when an explicit & is used and
+
@@ -14644,6 +14644,17 @@ QualType Sema::CheckAddressOfOperand(ExprResult
&OrigOp, SourceLocation OpLoc) {
return QualType();
}
+ // C++11 [expr.unary.op] p4:
+ // A pointer to member is only formed when an explicit & is used and
+
@@ -27,3 +26,20 @@ namespace rdar10544564 {
X (Y::*func_mem_ptr1)() = &Y::memfunc1;
X (Y::*func_mem_ptr2)() = &Y::memfunc2;
}
+
+namespace test2 {
cor3ntin wrote:
```suggestion
namespace GH40906 {
```
The test should probably be moved to
clang/test/CXX/e
https://github.com/arsenm approved this pull request.
I think this works for the test. I'm slightly confused by the PR not-stacking
with the test changes on top of the other PR
https://github.com/llvm/llvm-project/pull/89687
___
cfe-commits mailing l
https://github.com/sam-mccall created
https://github.com/llvm/llvm-project/pull/89729
Prior to this change, modulemaps describing textual headers are considered
to affect the current module whenever HeaderFileInfos for those headers exist.
This wastes creates false dependencies that (among othe
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Sam McCall (sam-mccall)
Changes
Prior to this change, modulemaps describing textual headers are considered
to affect the current module whenever HeaderFileInfos for those headers exist.
This wastes creates false dependencies that (among ot
https://github.com/fpetrogalli approved this pull request.
https://github.com/llvm/llvm-project/pull/89684
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/hokein created
https://github.com/llvm/llvm-project/pull/89731
Fixes https://github.com/llvm/llvm-project/issues/89723
>From 6d292f1d3bddb5a52ca63babd4bb785266277674 Mon Sep 17 00:00:00 2001
From: Haojian Wu
Date: Tue, 23 Apr 2024 11:48:12 +0200
Subject: [PATCH] [clang] coro
https://github.com/hokein edited https://github.com/llvm/llvm-project/pull/89731
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Haojian Wu (hokein)
Changes
Fixes https://github.com/llvm/llvm-project/issues/89723
---
Full diff: https://github.com/llvm/llvm-project/pull/89731.diff
4 Files Affected:
- (modified) clang/lib/CodeGen/CGCoroutine.cpp (+2-4)
- (modified
Author: Chuanqi Xu
Date: 2024-04-23T17:52:58+08:00
New Revision: b467c6b53660dcaa458c2b5d7fbf5f93ee2af910
URL:
https://github.com/llvm/llvm-project/commit/b467c6b53660dcaa458c2b5d7fbf5f93ee2af910
DIFF:
https://github.com/llvm/llvm-project/commit/b467c6b53660dcaa458c2b5d7fbf5f93ee2af910.diff
LO
https://github.com/ChuanqiXu9 approved this pull request.
LGTM. Thanks.
https://github.com/llvm/llvm-project/pull/89731
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/HerrCai0907 updated
https://github.com/llvm/llvm-project/pull/89497
>From 91915f68902ade86c0bf8eba643428017ae8bb3c Mon Sep 17 00:00:00 2001
From: Congcong Cai
Date: Sat, 20 Apr 2024 17:58:19 +0800
Subject: [PATCH 1/6] [tidy] add new check
bugprone-return-const-ref-from-param
https://github.com/HerrCai0907 updated
https://github.com/llvm/llvm-project/pull/89497
>From 91915f68902ade86c0bf8eba643428017ae8bb3c Mon Sep 17 00:00:00 2001
From: Congcong Cai
Date: Sat, 20 Apr 2024 17:58:19 +0800
Subject: [PATCH 1/7] [tidy] add new check
bugprone-return-const-ref-from-param
https://github.com/HerrCai0907 updated
https://github.com/llvm/llvm-project/pull/89497
>From 91915f68902ade86c0bf8eba643428017ae8bb3c Mon Sep 17 00:00:00 2001
From: Congcong Cai
Date: Sat, 20 Apr 2024 17:58:19 +0800
Subject: [PATCH 1/8] [tidy] add new check
bugprone-return-const-ref-from-param
spavloff wrote:
Thanks!
> Is there any existing bookkeeping we no longer need to do if we're going to
> have this RAII object in scope during function parsing?
It seems handling fast-math is the only case that prevented using this RAII
object.
https://github.com/llvm/llvm-project/pull/85605
sam-mccall wrote:
> @sam-mccall That makes sense.
>
> I think one option we have here is to consider all module maps describing a
> textual header that got included as affecting. I'm concerned that a long
> chain of textual header includes might again be problematic.
Yeah, that's the option t
@@ -458,6 +458,40 @@ let TargetGuard = "sme2,sme-f64f64" in {
def SVMLS_LANE_VG1x4_F64 : Inst<"svmls_lane_za64[_{d}]_vg1x4", "vm4di", "d",
MergeNone, "aarch64_sme_fmls_lane_vg1x4", [IsStreaming, IsInOutZA],
[ImmCheck<3, ImmCheck0_1>]>;
}
+let TargetGuard = "sme2p1,sme-f16f
ealcdan wrote:
Sure, I just updated my settings, thanks for the suggestion.
https://github.com/llvm/llvm-project/pull/85060
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dtemirbulatov deleted
https://github.com/llvm/llvm-project/pull/88380
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/weliveindetail created
https://github.com/llvm/llvm-project/pull/89734
This patch adds test coverage for an edge case that is supported already.
From 085a93919d8f65419cc856fe5584c83d3eceb142 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Tue, 23 Apr 2
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Stefan Gränitz (weliveindetail)
Changes
This patch adds test coverage for an edge case that is supported already.
---
Full diff: https://github.com/llvm/llvm-project/pull/89734.diff
1 Files Affected:
- (added) clang/test/Interpreter/for
cor3ntin wrote:
I'm not strongly opposed to merge that, however, i did confirm locally that
removing the call to `MaybeDestroyTemplateIds` in `ParseStatementOrDeclaration`
fixes the bug.
We currently destroy annotations
- At the end of a top level decl (and extern decl)
- At the end of a m
https://github.com/jasilvanus updated
https://github.com/llvm/llvm-project/pull/89228
>From 5d4a3b0f922b0c28960f610c695c92da7d3538c1 Mon Sep 17 00:00:00 2001
From: Jannik Silvanus
Date: Thu, 18 Apr 2024 14:56:47 +0200
Subject: [PATCH 1/2] [clang-format] Remove YAML hack to emit a BasedOnStyle
@@ -0,0 +1,13 @@
+// UNSUPPORTED: system-aix
+
+// RUN: cat %s | clang-repl | FileCheck %s
+int *x = new int();
+template struct GuardX { T *&x; GuardX(T *&x) : x(x) {}; ~GuardX();
};
+template GuardX::~GuardX() { delete x; x = nullptr; }
+
+// clang would normally defer codege
@@ -807,12 +807,18 @@ template <> struct MappingTraits {
FormatStyle PredefinedStyle;
if (getPredefinedStyle(StyleName, Style.Language, &PredefinedStyle) &&
Style == PredefinedStyle) {
- IO.mapOptional("# BasedOnStyle", StyleName);
+
jasilvanus wrote:
I've removed the dummy field and the comment now. This should prevent confusion.
I don't know whether anyone actually uses the emitted comment, there is no
explanation,
and tests pass without it.
I suggest that if we later learn that there are valid uses that require the
comm
weliveindetail wrote:
FYI: The run on the Windows bot failed even though tests worked as expected. In
particular, all `ClangReplInterpreterTests` unittests passed as well as all
`Interpreter` LIT tests. I could land this towards the end of the week.
https://github.com/llvm/llvm-project/pull/84
https://github.com/zahiraam approved this pull request.
LGTM. Thanks.
https://github.com/llvm/llvm-project/pull/89687
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aheejin wrote:
This first tried to enable four features (reference-types, multivalue,
bulk-memory, and nontrapping-fptoint), but I think now we can enable the two
first: reference-types and multivalue. These two were actually the first
motivation I started this (these are necessary for the new
https://github.com/PiotrZSL closed
https://github.com/llvm/llvm-project/pull/85060
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: ealcdan
Date: 2024-04-23T13:03:09+02:00
New Revision: c52b18d1e41107067b7557d8af3a06e6fe0beb0f
URL:
https://github.com/llvm/llvm-project/commit/c52b18d1e41107067b7557d8af3a06e6fe0beb0f
DIFF:
https://github.com/llvm/llvm-project/commit/c52b18d1e41107067b7557d8af3a06e6fe0beb0f.diff
LOG:
github-actions[bot] wrote:
@ealcdan Congratulations on having your first Pull Request (PR) merged into the
LLVM Project!
Your changes will be combined with recent changes from other authors, then
tested
by our [build bots](https://lab.llvm.org/buildbot/). If there is a problem with
a build,
zyn0217 wrote:
> I'm not strongly opposed to merge that, however, i did confirm locally that
> removing the call to `MaybeDestroyTemplateIds` in
> `ParseStatementOrDeclaration` fixes the bug.
>
> We currently destroy annotations
>
> * At the end of a top level decl (and extern decl)
> * At th
https://github.com/11happy updated
https://github.com/llvm/llvm-project/pull/84481
>From 8fdf6306085ed4cf0f77b7e718e374e9f65fedf9 Mon Sep 17 00:00:00 2001
From: 11happy
Date: Fri, 8 Mar 2024 19:02:47 +0530
Subject: [PATCH 01/14] add clang-tidy check
readability-math-missing-parentheses
Signed
11happy wrote:
hello @5chmidti I am sorry for my delayed response quite busy with my academic
work last week, I have added this change
```
if (EndLoc.isInvalid())
return;
```
this works fine for those macros.
Thank you
https://github.com/llvm/llvm-project/pull/84481
___
@@ -0,0 +1,13 @@
+// UNSUPPORTED: system-aix
+
+// RUN: cat %s | clang-repl | FileCheck %s
+int *x = new int();
+template struct GuardX { T *&x; GuardX(T *&x) : x(x) {}; ~GuardX();
};
+template GuardX::~GuardX() { delete x; x = nullptr; }
+
+// clang would normally defer codege
katzdm wrote:
> LGTM, thanks! Will you need me to merge the change for you?
@cor3ntin That would be great, thanks!
https://github.com/llvm/llvm-project/pull/89702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/m
edunad wrote:
@nicovank You're right ^^, it's better to just use negative regex, i'll close
this PR then
https://github.com/llvm/llvm-project/pull/89302
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
https://github.com/edunad closed https://github.com/llvm/llvm-project/pull/89302
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,194 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 4
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -target-feature +fullbf16
-S -emit-llvm %s -o - | FileCheck %s
+// CHECK-LABEL: define dso_local half @test
https://github.com/arsenm edited https://github.com/llvm/llvm-project/pull/89051
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/arsenm approved this pull request.
LGTM. Would be good to verify the vector case is "correct" in as far as it's
what GCC does
https://github.com/llvm/llvm-project/pull/89051
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h
@@ -1431,9 +1431,13 @@ Value *ScalarExprEmitter::EmitScalarCast(Value *Src,
QualType SrcType,
return Builder.CreateFPToUI(Src, DstTy, "conv");
}
- if (DstElementTy->getTypeID() < SrcElementTy->getTypeID())
+ if ((DstElementTy->is16bitFPTy() && SrcElementTy->is16bitFPT
cor3ntin wrote:
> > > This approach is doable technically, but it feels hacky and fragile. What
> > > if we emit an error (or warning) diagnostic and reject the code when we
> > > parse the __is_deducible type trait?
> >
> >
> > Why do you think it is fragile? I think a comment around `BTT_Is
https://github.com/weliveindetail updated
https://github.com/llvm/llvm-project/pull/89734
From 085a93919d8f65419cc856fe5584c83d3eceb142 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Gr=C3=A4nitz?=
Date: Tue, 23 Apr 2024 12:23:11 +0200
Subject: [PATCH 1/2] [clang-repl] Add test for explicit
https://github.com/zmodem approved this pull request.
lgtm
Both changes mentioned in the description are old-ish. Maybe expand it to cover
what was the recent change triggering the need for a flag?
https://github.com/llvm/llvm-project/pull/89642
___
@@ -656,19 +656,29 @@ std::string ToolChain::getCompilerRT(const ArgList &Args,
StringRef Component,
// Check for runtime files in the new layout without the architecture first.
std::string CRTBasename =
buildCompilerRTBasename(Args, Component, Type, /*AddArch=*/fals
nico wrote:
This is a behavior change: In distributed build environments, neither lib file
exists at compile time. Previously, this would result in the "old" style, now
(together with #81037) it results in the "new" style (which we disable
everywhere since it causes all kinds of issues – from
https://github.com/nico updated https://github.com/llvm/llvm-project/pull/89642
>From 39bd2d2ece1f55c3c77e1f376913846fb604be27 Mon Sep 17 00:00:00 2001
From: Nico Weber
Date: Mon, 22 Apr 2024 14:05:04 -0400
Subject: [PATCH] clang/win: Add a flag to disable default-linking of
compiler-rt librari
https://github.com/nico edited https://github.com/llvm/llvm-project/pull/89642
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/89713
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nico wrote:
Good call-out, thanks. I meant #87866, which is new.
I also forgot that llvm-project likes to do squash commits and put the new
commit message in the old commit and `git push -f`'d. But the only thing that
changed in the new commit is the commit message text.
https://github.com/ll
https://github.com/AaronBallman commented:
Thank you for the fix! You should also add a release note to
clang/docs/ReleaseNotes.rst so that users know about the improvement.
https://github.com/llvm/llvm-project/pull/89713
___
cfe-commits mailing list
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/89713
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -14644,6 +14644,17 @@ QualType Sema::CheckAddressOfOperand(ExprResult
&OrigOp, SourceLocation OpLoc) {
return QualType();
}
+ // C++11 [expr.unary.op] p4:
+ // A pointer to member is only formed when an explicit & is used and
+
mstorsjo wrote:
> This is a behavior change: In distributed build environments, neither lib
> file exists at compile time. Previously, this would result in the "old"
> style, now (together with #81037) it results in the "new" style (which we
> disable everywhere since it causes all kinds of is
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/89494
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Meinersbur edited
https://github.com/llvm/llvm-project/pull/89153
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
Precommit CI is currently failing on libc++ tests that are impacted by this
change; should I solve those as part of this patch or are you okay with fixing
those after this patch lands? (Or would you like to push a fix to this branch?)
https://github.com/llvm/llvm-project/pu
https://github.com/AaronBallman commented:
Oops, I misunderstood what @cor3ntin was saying. One moment while I re-think
now that I have understood his point better.
https://github.com/llvm/llvm-project/pull/89494
___
cfe-commits mailing list
cfe-commi
Author: Younan Zhang
Date: 2024-04-23T20:34:22+08:00
New Revision: 8ab3caf4d3acef29f373e09bc6a0ac459918930e
URL:
https://github.com/llvm/llvm-project/commit/8ab3caf4d3acef29f373e09bc6a0ac459918930e
DIFF:
https://github.com/llvm/llvm-project/commit/8ab3caf4d3acef29f373e09bc6a0ac459918930e.diff
https://github.com/zyn0217 closed
https://github.com/llvm/llvm-project/pull/89494
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zyn0217 wrote:
Oops. I thought there was some latency between clicking the merge button and
your latest comment. Should I revert?
https://github.com/llvm/llvm-project/pull/89494
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llv
AaronBallman wrote:
> Oops. I thought there was some latency between clicking the merge button and
> your latest comment. Should I revert?
No worries, I should have hit `Request Changes` instead of `Comment`. :-) No
need to revert yet.
https://github.com/llvm/llvm-project/pull/89494
_
https://github.com/revane updated
https://github.com/llvm/llvm-project/pull/88735
>From 5be7a57838b8fe7042e0719911670f6f369db2e8 Mon Sep 17 00:00:00 2001
From: Edwin Vane
Date: Thu, 28 Mar 2024 09:30:32 -0400
Subject: [PATCH] [clang-tidy] Refactor how NamedDecl are renamed
The handling of rena
https://github.com/zmodem created
https://github.com/llvm/llvm-project/pull/89751
The C++ standard requires that symmetric transfer from one coroutine to another
is performed via a tail call. Failure to do so is a miscompile and often breaks
programs by quickly overflowing the stack.
Until no
zyn0217 wrote:
> > Oops. I thought there was some latency between clicking the merge button
> > and your latest comment. Should I revert?
>
> No worries, I should have hit `Request Changes` instead of `Comment`. :-) No
> need to revert yet.
OK, so if you feel that approach is better, I think
llvmbot wrote:
@llvm/pr-subscribers-coroutines
Author: Hans (zmodem)
Changes
The C++ standard requires that symmetric transfer from one coroutine to another
is performed via a tail call. Failure to do so is a miscompile and often breaks
programs by quickly overflowing the stack.
Until n
zmodem wrote:
What do you think?
(The test updates are a bit hacky for now, but I wanted to get feedback before
spending more time on them. Also I think many of the tests become uninteresting
after this patch and could probably be deleted.)
https://github.com/llvm/llvm-project/pull/89751
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff c52b18d1e41107067b7557d8af3a06e6fe0beb0f
33b07efe6d68cb4d17e96349b552ef5e5901d8c6 --
Troy-Butler wrote:
I do not have the ability to merge, so if everything looks good with my pull
request, can the last reviewer please merge this? Thank you!
https://github.com/llvm/llvm-project/pull/89512
___
cfe-commits mailing list
cfe-commits@lists
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/89751
>From 33b07efe6d68cb4d17e96349b552ef5e5901d8c6 Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Tue, 26 Mar 2024 15:04:35 +0100
Subject: [PATCH 1/2] stuff
---
clang/lib/CodeGen/CGCoroutine.cpp |
https://github.com/frasercrmck created
https://github.com/llvm/llvm-project/pull/89756
We've recently seen the libclc llvm-link invocations become so long that they
exceed the character limits on certain platforms.
Using a 'response file' should solve this by offloading the list of inputs into
1 - 100 of 523 matches
Mail list logo
