zixuan-wu added a comment.
ping?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D70401/new/
https://reviews.llvm.org/D70401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
Author: Brad Smith
Date: 2023-10-09T00:49:53-04:00
New Revision: 7cfe32d4d8da6eb6ea558a584a3a52e2e8a97a3c
URL:
https://github.com/llvm/llvm-project/commit/7cfe32d4d8da6eb6ea558a584a3a52e2e8a97a3c
DIFF:
https://github.com/llvm/llvm-project/commit/7cfe32d4d8da6eb6ea558a584a3a52e2e8a97a3c.diff
https://github.com/brad0 closed https://github.com/llvm/llvm-project/pull/67222
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Xinlong-Wu closed
https://github.com/llvm/llvm-project/pull/68551
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Xinlong-Wu wrote:
> > > > This patch is moved from https://reviews.llvm.org/D134600
> > >
> > >
> > > Why? That loses all the context in the Phabricator review. Keep the
> > > review there.
> >
> >
> > yes, I will keep it there.
> > But the [Phabricator shutdown
> >
https://github.com/Xinlong-Wu closed
https://github.com/llvm/llvm-project/pull/68551
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
michalpaszkowski wrote:
> Please don't use the term canon/canonicalize for this pass or tool. LLVM has
> an existing notion of "canonicalization" which does not coincide with what is
> being done here.
@nikic I don't think the name "canon" or "canonicalizer" will lead to any
confusion here.
michalpaszkowski wrote:
> Please don't use the term canon/canonicalize for this pass or tool. LLVM has
> an existing notion of "canonicalization" which does not coincide with what is
> being done here.
@nikic I don't think the name "canon" or "canonicalizer" will lead to any
confusion here.
jrtc27 wrote:
> > > This patch is moved from https://reviews.llvm.org/D134600
> >
> >
> > Why? That loses all the context in the Phabricator review. Keep the review
> > there.
>
> yes, I will keep it there.
>
> But the [Phabricator shutdown
>
plotfi wrote:
> Please don't use the term canon/canonicalize for this pass or tool. LLVM has
> an existing notion of "canonicalization" which does not coincide with what is
> being done here.
The term comes from an older pass that did similar algorithms on MIR. They are
only borrowing the
plotfi wrote:
> Please don't use the term canon/canonicalize for this pass or tool. LLVM has
> an existing notion of "canonicalization" which does not coincide with what is
> being done here.
The term comes from an older pass that did similar algorithms on MIR. They are
only borrowing the
Xinlong-Wu wrote:
> > This patch is moved from https://reviews.llvm.org/D134600
>
> Why? That loses all the context in the Phabricator review. Keep the review
> there.
yes, I will keep it there.
But the [Phabricator shutdown
Xinlong-Wu wrote:
> > This patch is moved from https://reviews.llvm.org/D134600
>
> Why? That loses all the context in the Phabricator review. Keep the review
> there.
yes, I will keep it there.
But the [Phabricator shutdown
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 7cc1bfaf371c4a816cf4e62fe31d8515bf8f6fbd
20d59b945dcd57fb523118e3116492a2863a7b4d --
jrtc27 wrote:
> This patch is moved from https://reviews.llvm.org/D134600
Why? That loses all the context in the Phabricator review. Keep the review
there.
https://github.com/llvm/llvm-project/pull/68551
___
cfe-commits mailing list
https://github.com/s-barannikov updated
https://github.com/llvm/llvm-project/pull/68550
>From 7199c73d5c9dc04c5c4a1915fc9f5bb0e824d40a Mon Sep 17 00:00:00 2001
From: Sergei Barannikov
Date: Mon, 9 Oct 2023 01:38:33 +0300
Subject: [PATCH] [clang] Differentiate between identifier and string
@@ -45,7 +45,7 @@ int __attribute__((pcs("aapcs", "aapcs"))) pcs1(void); //
expected-error {{'pcs'
int __attribute__((pcs())) pcs2(void); // expected-error {{'pcs' attribute
takes one argument}}
int __attribute__((pcs(pcs1))) pcs3(void); // expected-error {{'pcs' attribute
s-barannikov wrote:
I'll add some test for 'interrupt' attribute that is the only attribute
affected by `emitClangAttrUnevaluatedStringLiteralList` changes.
https://github.com/llvm/llvm-project/pull/68550
___
cfe-commits mailing list
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 7cc1bfaf371c4a816cf4e62fe31d8515bf8f6fbd
eb100a554b6802df794a966c81820873823fa1b3 --
https://github.com/s-barannikov edited
https://github.com/llvm/llvm-project/pull/68550
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/s-barannikov created
https://github.com/llvm/llvm-project/pull/68550
EnumArgument may be a string or an identifier. If it is a string, it should be
parsed as unevaluated string literal. Add IsString flag to EnumArgument so that
the parser can choose the correct parsing
brad0 wrote:
@nielx
https://github.com/llvm/llvm-project/pull/67872
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
brad0 wrote:
@nielx
https://github.com/llvm/llvm-project/pull/67222
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jacquesguan approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/68484
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
> This doesn't seem all that useful/important to me - a user can move the body
> of the function into an implementation unit rather than putting it in the
> interface unit and marking it noinline, right? This is the same
> recommendation we'd make if someone wrote a complex
hvdijk added inline comments.
Comment at: llvm/lib/IR/AutoUpgrade.cpp:5233
+ SmallVector Groups;
+ Regex R("(.*-i64:64)(-.*)");
+ if (R.match(Res, ))
hvdijk wrote:
> nikic wrote:
> > I don't think this will work for the 32-bit targets that don't
https://github.com/owenca approved this pull request.
https://github.com/llvm/llvm-project/pull/68534
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
philnik777 wrote:
@jyknight I don't think we have to worry much about that. The step count is
quite arbitrary (maybe something like AST nodes?) and doesn't seem to have
anything to do with the actual cost or compile time of the program. e.g. a
`__builtin_memmove` of arbitrary size and a
philnik777 wrote:
@jyknight I don't think we have to worry much about that. The step count is
quite arbitrary (maybe something like AST nodes?) and doesn't seem to have
anything to do with the actual cost or compile time of the program. e.g. a
`__builtin_memmove` of arbitrary size and a
jyknight wrote:
Looks like the debug/hardened/safe mode tests are failing
libcxx/std/utilities/template.bitset/bitset.members/to_string.pass.cpp because
the constant evaluations for
```
static_assert(test_to_string<64>());
static_assert(test_to_string<65>());
```
now both hit the constant
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/66576
>From 209a8f9c06a7633737e9f022bc4e61d580ad95e7 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Sat, 16 Sep 2023 12:32:21 +
Subject: [PATCH 1/6] [libcxx] Allow string to use SSO in constant evaluation.
ax3l wrote:
Thank you! :tada:
https://github.com/llvm/llvm-project/pull/68491
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/HerrCai0907 closed
https://github.com/llvm/llvm-project/pull/68491
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Congcong Cai
Date: 2023-10-09T07:20:23+08:00
New Revision: 7cc1bfaf371c4a816cf4e62fe31d8515bf8f6fbd
URL:
https://github.com/llvm/llvm-project/commit/7cc1bfaf371c4a816cf4e62fe31d8515bf8f6fbd
DIFF:
https://github.com/llvm/llvm-project/commit/7cc1bfaf371c4a816cf4e62fe31d8515bf8f6fbd.diff
=?utf-8?q?Bj=C3=B6rn_Sch=C3=A4pers?=
Message-ID:
In-Reply-To:
owenca wrote:
See https://github.com/llvm/llvm-project/issues/56636.
https://github.com/llvm/llvm-project/pull/68535
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
=?utf-8?q?Bj=C3=B6rn_Sch=C3=A4pers?=
Message-ID:
In-Reply-To:
https://github.com/owenca approved this pull request.
https://github.com/llvm/llvm-project/pull/68535
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
Timm =?utf-8?q?Bäder?=
Message-ID:
In-Reply-To:
https://github.com/aaronpuchert commented:
> This was much easier than expected actually.
Making it a `DeclOrType` attribute is indeed a nice idea, this would allow
existing attributes to stay where they are. Is it still inheritable, i.e. does
Timm =?utf-8?q?Bäder?=
Message-ID:
In-Reply-To:
@@ -136,6 +136,17 @@ int main(void) {
// Cleanup happens automatically -> no warning.
}
+ /// Function pointers
+ {
+int __attribute__((requires_capability())) (*function_ptr)(int) =
Foo_fun1;
Timm =?utf-8?q?Bäder?=
Message-ID:
In-Reply-To:
@@ -8141,6 +8141,16 @@ static void handleRequiresCapabilityAttr(Sema , Decl
*D,
if (!AL.checkAtLeastNumArgs(S, 1))
return;
+ // We allow this on function declaration as well as
+ // variable declarations of function
Timm =?utf-8?q?Bäder?=
Message-ID:
In-Reply-To:
https://github.com/aaronpuchert edited
https://github.com/llvm/llvm-project/pull/67095
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/dwblaikie approved this pull request.
https://github.com/llvm/llvm-project/pull/68501
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
*shrug* I guess it's OK.
https://github.com/llvm/llvm-project/pull/68501
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
barannikov88 updated this revision to Diff 557644.
barannikov88 added a comment.
Add a hyphen
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D159393/new/
https://reviews.llvm.org/D159393
Files:
clang/docs/ReleaseNotes.rst
barannikov88 added a comment.
@aaron.ballman I added a release note as requested. Please see if it looks the
way it should.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D159393/new/
https://reviews.llvm.org/D159393
barannikov88 updated this revision to Diff 557643.
barannikov88 added a comment.
Add a release note
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D159393/new/
https://reviews.llvm.org/D159393
Files:
clang/docs/ReleaseNotes.rst
=?utf-8?q?Björn_Schäpers?=
Message-ID:
In-Reply-To:
llvmbot wrote:
@llvm/pr-subscribers-clang-format
Changes
This review is only for the second commit.
Is there a way to build pull request upon each other?
---
Full diff: https://github.com/llvm/llvm-project/pull/68535.diff
3 Files
https://github.com/HazardyKnusperkeks created
https://github.com/llvm/llvm-project/pull/68535
This review is only for the second commit.
Is there a way to build pull request upon each other?
From f8b65d778b81e2dccc6773303d4b17843078864c Mon Sep 17 00:00:00 2001
From:
https://github.com/HazardyKnusperkeks updated
https://github.com/llvm/llvm-project/pull/68534
From f8b65d778b81e2dccc6773303d4b17843078864c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Sch=C3=A4pers?=
Date: Sun, 8 Oct 2023 22:12:28 +0200
Subject: [PATCH] [clang-format][NFC] Annotate
llvmbot wrote:
@llvm/pr-subscribers-clang-format
Changes
In preparation of #67906.
---
Full diff: https://github.com/llvm/llvm-project/pull/68534.diff
3 Files Affected:
- (modified) clang/lib/Format/FormatToken.h (+4)
- (modified) clang/lib/Format/UnwrappedLineParser.cpp (+10-6)
-
https://github.com/HazardyKnusperkeks created
https://github.com/llvm/llvm-project/pull/68534
In preparation of #67906.
From 28c69947fb451db2176284f162c789b081600209 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Sch=C3=A4pers?=
Date: Sun, 8 Oct 2023 22:12:28 +0200
Subject: [PATCH]
iains wrote:
A possible mechanism might be to have a watchdog process, with which instances
of the server are registered with a time-to-live. I guess this might be easier
to construct as a scheme for test-suites than for end-user.
https://github.com/llvm/llvm-project/pull/67562
philnik777 wrote:
> This doesn't seem all that useful/important to me - a user can move the body
> of the function into an implementation unit rather than putting it in the
> interface unit and marking it noinline, right? This is the same
> recommendation we'd make if someone wrote a complex
dwblaikie wrote:
This doesn't seem all that useful/important to me - a user can move the body of
the function into an implementation unit rather than putting it in the
interface unit and marking it noinline, right? This is the same recommendation
we'd make if someone wrote a complex function
barannikov88 updated this revision to Diff 557642.
barannikov88 added a comment.
Rebase
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D159393/new/
https://reviews.llvm.org/D159393
Files:
clang/test/Preprocessor/has_attribute.c
royjacobson added a comment.
I, uh, got preoccupied by some recent events. Don't think I'll have the time
for this unfortunately.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D154893/new/
https://reviews.llvm.org/D154893
MaskRay wrote:
> @zygoloid Thanks for the explanation! I wasn't aware this fell under
> unspecified behavior. It's weird that alignment information can survive a
> `void *` cast, but it does make some sense.
Yes, `(void *)x` decreases the alignment requirement to 1 byte like `(char *)x`.
>
nikic added a comment.
FYI this causes some compile-time regression:
http://llvm-compile-time-tracker.com/compare.php?from=bc7d88faf1a595ab59952a2054418cdd0d98=af4751738db89a142a8880c782d12d4201b222a8=instructions:u
About 0.7% for C++ code at `O0`. Sample for a file with >2% would be
https://github.com/AMP999 updated
https://github.com/llvm/llvm-project/pull/68506
>From ae2cd56b1c68353aae6c74524e71973ce6ca6904 Mon Sep 17 00:00:00 2001
From: Amirreza Ashouri
Date: Sat, 7 Oct 2023 19:02:34 +0330
Subject: [PATCH 1/2] [clang] Rename some misleading names (Non-functional)
https://github.com/bc-lee updated
https://github.com/llvm/llvm-project/pull/68525
>From b272173acb8c2f92b5c5b7ebca4c00e4ac21037c Mon Sep 17 00:00:00 2001
From: Byoungchan Lee
Date: Sun, 8 Oct 2023 21:47:05 +0900
Subject: [PATCH] [Clang][Frontend] Fix a crash when -Wdocumentation is used
This
https://github.com/phoebewang approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/68517
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/SuperSodaSea edited
https://github.com/llvm/llvm-project/pull/68485
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/SuperSodaSea updated
https://github.com/llvm/llvm-project/pull/68485
>From 03276260c48d9cafb2a0d80825156e77cdf02eba Mon Sep 17 00:00:00 2001
From: SuperSodaSea
Date: Sat, 7 Oct 2023 21:05:17 +0800
Subject: [PATCH 1/2] [clang] static operators should evaluate object argument
llvmbot wrote:
@llvm/pr-subscribers-clang
Changes
This commit resolves a crash issue in Clang's frontend caused while using the
`-Wdocumentation` compiler flag.
The flaw was due to the lack of necessary checks before the extraction of text
between the comment and the declaration in the
https://github.com/bc-lee created
https://github.com/llvm/llvm-project/pull/68525
This commit resolves a crash issue in Clang's frontend caused while using the
`-Wdocumentation` compiler flag.
The flaw was due to the lack of necessary checks before the extraction of text
between the comment
https://github.com/AMP999 updated
https://github.com/llvm/llvm-project/pull/68506
>From ae2cd56b1c68353aae6c74524e71973ce6ca6904 Mon Sep 17 00:00:00 2001
From: Amirreza Ashouri
Date: Sat, 7 Oct 2023 19:02:34 +0330
Subject: [PATCH 1/2] [clang] Rename some misleading names (Non-functional)
https://github.com/FreddyLeaf approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/68517
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvmbot wrote:
@llvm/pr-subscribers-libunwind
Changes
Libunwind supports FP64 and FP32 modes, but not FPXX. The reason is that, FP64
and FP32 have different way to save/restore FPRs. If libunwind is built as
FPXX, we have no idea which one should we use.
If libunwind is built as FP64,
https://github.com/wzssyqa created
https://github.com/llvm/llvm-project/pull/68521
Libunwind supports FP64 and FP32 modes, but not FPXX. The reason is that, FP64
and FP32 have different way to save/restore FPRs. If libunwind is built as
FPXX, we have no idea which one should we use.
If
https://github.com/XinWang10 created
https://github.com/llvm/llvm-project/pull/68517
None
>From 64bd9a87f3043ee6dcab15f8444902657031539c Mon Sep 17 00:00:00 2001
From: XinWang10
Date: Sun, 8 Oct 2023 17:45:32 +0800
Subject: [PATCH] [X86][NFC]Update test cases after D159250
---
llvmbot wrote:
@llvm/pr-subscribers-clang
Changes
Previously `__builtin_printf` would result to emitting call to `printf`, even
though directly calling `printf` was translated.
Ref: #68478
---
Full diff: https://github.com/llvm/llvm-project/pull/68515.diff
4 Files Affected:
-
https://github.com/Maetveis created
https://github.com/llvm/llvm-project/pull/68515
Previously `__builtin_printf` would result to emitting call to `printf`, even
though directly calling `printf` was translated.
Ref: #68478
From 193c652ac8a7a387ce99a63cd09b17bdc44f20a1 Mon Sep 17 00:00:00
vabridgers wrote:
Hi @AaronBallman , I ran a compile using this change on clang as you asked and
have results. The compile ran with no crashes or errors, and produced 1478
bitfield-conversion warnings. I'll show a few examples below. To put that
number into context, I enabled -Wconversion to
https://github.com/jcsxky updated
https://github.com/llvm/llvm-project/pull/68510
>From b0f13442dd6c41331f9ab43f1cd8ac6bbf0deabe Mon Sep 17 00:00:00 2001
From: huqizhi
Date: Sun, 8 Oct 2023 16:00:29 +0800
Subject: [PATCH] [clang][analysis]Use dyn_cast_or_null instead cast to prevent
crash
https://github.com/jcsxky edited https://github.com/llvm/llvm-project/pull/68510
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jcsxky edited https://github.com/llvm/llvm-project/pull/68510
___
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-analysis
Changes
`getStorageLocation` may return `nullptr` and this will produce crash when use
`cast`, use `dyn_cast_or_null` instead. I test it locally using
[FTXUI](https://github.com/ArthurSonzogni/FTXUI) and it may be the cause of
issue
https://github.com/jcsxky created
https://github.com/llvm/llvm-project/pull/68510
`getStorageLocation` may return `nullptr` and this will produce crash when use
`cast`, use `dyn_cast_or_null` instead. I test it locally using
[FTXUI](https://github.com/ArthurSonzogni/FTXUI) and it may be the
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/68501
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/benshi001 updated
https://github.com/llvm/llvm-project/pull/68507
>From f13fad7cfcfbf654052d595cf3dd985fbaefeb76 Mon Sep 17 00:00:00 2001
From: Ben Shi
Date: Sun, 8 Oct 2023 15:00:32 +0800
Subject: [PATCH] [clang][driver] Add avr-libc's default linker script to lld
If
llvmbot wrote:
@llvm/pr-subscribers-clang
Changes
If `-fuse-ld=lld` is specified but no user linker script is offered, we try to
use avr-libc's default one for lld. (not needed for GNU ld)
---
Full diff: https://github.com/llvm/llvm-project/pull/68507.diff
4 Files Affected:
-
https://github.com/benshi001 created
https://github.com/llvm/llvm-project/pull/68507
If `-fuse-ld=lld` is specified but no user linker script is offered, we try to
use avr-libc's default one for lld. (not needed for GNU ld)
>From 2ac033cc4750ffda8f1aded4b896de93713047ad Mon Sep 17 00:00:00
https://github.com/AviadCo updated
https://github.com/llvm/llvm-project/pull/67808
>From a760c42f0c8b75361f822e1efcbdae30151b2180 Mon Sep 17 00:00:00 2001
From: Aviad Cohen
Date: Fri, 29 Sep 2023 15:32:18 +0300
Subject: [PATCH] [mlir][memref]: Add expand/collapse rewrite pattern to
https://github.com/AviadCo updated
https://github.com/llvm/llvm-project/pull/67808
>From a760c42f0c8b75361f822e1efcbdae30151b2180 Mon Sep 17 00:00:00 2001
From: Aviad Cohen
Date: Fri, 29 Sep 2023 15:32:18 +0300
Subject: [PATCH] [mlir][memref]: Add expand/collapse rewrite pattern to
https://github.com/benshi001 updated
https://github.com/llvm/llvm-project/pull/68484
>From 88e173ea772e2b4996c874a093bab087d5c98187 Mon Sep 17 00:00:00 2001
From: Ben Shi
Date: Sat, 7 Oct 2023 20:49:36 +0800
Subject: [PATCH] [clang][driver] Support option '-r' for target AVR
If '-r' is
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 18622fc2f4bcd58f9076301babdfbcca9c0a70d0
ef0ad97b1dee9f4d7547f551b4b8b96a51221c51 --
llvmbot wrote:
@llvm/pr-subscribers-clang
Changes
Lambdas (closure types) are trivially equality-comparable iff they are
non-capturing, because non-capturing lambdas are convertible to function
pointers: if (lam1 == lam2) compiles, then lam1 and lam2 must have
the same type, and be
https://github.com/AMP999 created
https://github.com/llvm/llvm-project/pull/68506
Lambdas (closure types) are trivially equality-comparable iff they are
non-capturing, because non-capturing lambdas are convertible to function
pointers: if (lam1 == lam2) compiles, then lam1 and lam2 must have
87 matches
Mail list logo
