On Mon, Apr 11, 2022 at 12:14 PM Aaron Ballman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> On Mon, Apr 11, 2022 at 10:50 AM Joerg Sonnenberger via Phabricator <
> revi...@reviews.llvm.org> wrote:
> >
> > joerg added a comment.
> >
> > The patch contains at least one user visible change
Author: Arthur O'Dwyer
Date: 2022-03-04T12:43:06-05:00
New Revision: f0891cd61b2f7cd57d906406ae785722bfd87603
URL:
https://github.com/llvm/llvm-project/commit/f0891cd61b2f7cd57d906406ae785722bfd87603
DIFF:
https://github.com/llvm/llvm-project/commit/f0891cd61b2f7cd57d906406ae785722bfd87603.diff
Author: Arthur O'Dwyer
Date: 2022-03-04T12:43:05-05:00
New Revision: adf6703f75b09564ca887b0eea0c3b37e65237d7
URL:
https://github.com/llvm/llvm-project/commit/adf6703f75b09564ca887b0eea0c3b37e65237d7
DIFF:
https://github.com/llvm/llvm-project/commit/adf6703f75b09564ca887b0eea0c3b37e65237d7.diff
Author: Arthur O'Dwyer
Date: 2022-02-28T12:27:34-05:00
New Revision: d3db74eadbfc06425668b39c41eeeca22f747978
URL:
https://github.com/llvm/llvm-project/commit/d3db74eadbfc06425668b39c41eeeca22f747978
DIFF:
https://github.com/llvm/llvm-project/commit/d3db74eadbfc06425668b39c41eeeca22f747978.diff
I thought I caught all of them, too! I encourage someone with commit rights
to land the missing five characters "std::" right now, and/or I'll be able
to take my own look in about 6 hours from now.
Arthur
On Thu, Feb 24, 2022, 2:06 PM Corentin Jabot via Phabricator <
revi...@reviews.llvm.org> wr
Author: Arthur O'Dwyer
Date: 2022-02-17T11:56:49-05:00
New Revision: 7adb85884b35be033b6c54d5916aed5edcb354fb
URL:
https://github.com/llvm/llvm-project/commit/7adb85884b35be033b6c54d5916aed5edcb354fb
DIFF:
https://github.com/llvm/llvm-project/commit/7adb85884b35be033b6c54d5916aed5edcb354fb.diff
Author: Arthur O'Dwyer
Date: 2022-02-16T10:42:58-05:00
New Revision: 597f2bcee895c1a9cc18067b85d6846137c11816
URL:
https://github.com/llvm/llvm-project/commit/597f2bcee895c1a9cc18067b85d6846137c11816
DIFF:
https://github.com/llvm/llvm-project/commit/597f2bcee895c1a9cc18067b85d6846137c11816.diff
Author: Arthur O'Dwyer
Date: 2022-02-14T11:28:32-05:00
New Revision: 3c8d2aa87c1701ca16e13f06aea484637e03d005
URL:
https://github.com/llvm/llvm-project/commit/3c8d2aa87c1701ca16e13f06aea484637e03d005
DIFF:
https://github.com/llvm/llvm-project/commit/3c8d2aa87c1701ca16e13f06aea484637e03d005.diff
Author: Arthur O'Dwyer
Date: 2022-02-14T11:28:23-05:00
New Revision: 528deedd582f6f11cf1bba478e5e4645f4baf04f
URL:
https://github.com/llvm/llvm-project/commit/528deedd582f6f11cf1bba478e5e4645f4baf04f
DIFF:
https://github.com/llvm/llvm-project/commit/528deedd582f6f11cf1bba478e5e4645f4baf04f.diff
Author: Arthur O'Dwyer
Date: 2022-02-01T15:17:28-05:00
New Revision: c0185ffaec3cb0aa7677b13a898eaa485ef29421
URL:
https://github.com/llvm/llvm-project/commit/c0185ffaec3cb0aa7677b13a898eaa485ef29421
DIFF:
https://github.com/llvm/llvm-project/commit/c0185ffaec3cb0aa7677b13a898eaa485ef29421.diff
Author: Arthur O'Dwyer
Date: 2022-02-01T15:16:17-05:00
New Revision: f6ce456707898f0ae2c70748e896130e1c897960
URL:
https://github.com/llvm/llvm-project/commit/f6ce456707898f0ae2c70748e896130e1c897960
DIFF:
https://github.com/llvm/llvm-project/commit/f6ce456707898f0ae2c70748e896130e1c897960.diff
Author: Arthur O'Dwyer
Date: 2022-01-29T10:20:22-05:00
New Revision: 424400da2db86558917e6da19a821e160acc48d1
URL:
https://github.com/llvm/llvm-project/commit/424400da2db86558917e6da19a821e160acc48d1
DIFF:
https://github.com/llvm/llvm-project/commit/424400da2db86558917e6da19a821e160acc48d1.diff
Author: Arthur O'Dwyer
Date: 2022-01-27T17:36:08-05:00
New Revision: f9a00b3cbc580cf79688fa813c6e898e90b4fd43
URL:
https://github.com/llvm/llvm-project/commit/f9a00b3cbc580cf79688fa813c6e898e90b4fd43
DIFF:
https://github.com/llvm/llvm-project/commit/f9a00b3cbc580cf79688fa813c6e898e90b4fd43.diff
Author: Arthur O'Dwyer
Date: 2022-01-27T14:21:50-05:00
New Revision: 9be5f4d5afd9a1b6e88a268f6ea6eb282d77d9fe
URL:
https://github.com/llvm/llvm-project/commit/9be5f4d5afd9a1b6e88a268f6ea6eb282d77d9fe
DIFF:
https://github.com/llvm/llvm-project/commit/9be5f4d5afd9a1b6e88a268f6ea6eb282d77d9fe.diff
Hi Aaron,
FWIW, I like your new wording (and rationale for it) better than the old
wording. Of course I've got a conflict of interest, because of P1144
[[trivially_relocatable]] and P2266 "Simpler implicit move" and so on. ;)
This sentence in particular, though...
> Clang should drive the standar
Author: Arthur O'Dwyer
Date: 2021-09-11T13:44:51-05:00
New Revision: 2b4cad5e471c60edae528979fa5f3edde844ac34
URL:
https://github.com/llvm/llvm-project/commit/2b4cad5e471c60edae528979fa5f3edde844ac34
DIFF:
https://github.com/llvm/llvm-project/commit/2b4cad5e471c60edae528979fa5f3edde844ac34.diff
Author: Arthur O'Dwyer
Date: 2021-03-23T14:12:06-04:00
New Revision: 5f1de9cab1ce2fbb1e45239d3e0e8d4970d2124e
URL:
https://github.com/llvm/llvm-project/commit/5f1de9cab1ce2fbb1e45239d3e0e8d4970d2124e
DIFF:
https://github.com/llvm/llvm-project/commit/5f1de9cab1ce2fbb1e45239d3e0e8d4970d2124e.diff
Author: Yang Fan
Date: 2021-02-16T17:24:20-05:00
New Revision: fbee4a0c79cc4ee87c34e51342742a5bc6fcf872
URL:
https://github.com/llvm/llvm-project/commit/fbee4a0c79cc4ee87c34e51342742a5bc6fcf872
DIFF:
https://github.com/llvm/llvm-project/commit/fbee4a0c79cc4ee87c34e51342742a5bc6fcf872.diff
LOG:
Author: Arthur O'Dwyer
Date: 2020-12-22T19:54:29-05:00
New Revision: 22cf54a7fba670642c121684ac3c7ff7e35dfa5c
URL:
https://github.com/llvm/llvm-project/commit/22cf54a7fba670642c121684ac3c7ff7e35dfa5c
DIFF:
https://github.com/llvm/llvm-project/commit/22cf54a7fba670642c121684ac3c7ff7e35dfa5c.diff
Author: Arthur O'Dwyer
Date: 2020-12-01T22:13:40-05:00
New Revision: e181a6aeddc26ef0512b2dba94db6360ba32f2ff
URL:
https://github.com/llvm/llvm-project/commit/e181a6aeddc26ef0512b2dba94db6360ba32f2ff
DIFF:
https://github.com/llvm/llvm-project/commit/e181a6aeddc26ef0512b2dba94db6360ba32f2ff.diff
Author: Arthur O'Dwyer
Date: 2020-12-01T22:13:40-05:00
New Revision: e181a6aeddc26ef0512b2dba94db6360ba32f2ff
URL:
https://github.com/llvm/llvm-project/commit/e181a6aeddc26ef0512b2dba94db6360ba32f2ff
DIFF:
https://github.com/llvm/llvm-project/commit/e181a6aeddc26ef0512b2dba94db6360ba32f2ff.diff
Author: Yang Fan
Date: 2020-11-10T15:11:07-05:00
New Revision: 703038b35a864d06e1926237c1568a430417b0b4
URL:
https://github.com/llvm/llvm-project/commit/703038b35a864d06e1926237c1568a430417b0b4
DIFF:
https://github.com/llvm/llvm-project/commit/703038b35a864d06e1926237c1568a430417b0b4.diff
LOG:
Dávid: Please just disable it for initializers of structs. That seems to be
the common denominator in all the false positives I've observed on this
thread.
On Tue, Aug 11, 2020 at 3:07 PM Dávid Bolvanský
wrote:
> Ok, I will bump that limit + 1.
>
> ut 11. 8. 2020 o 20:52 Arthur Eubanks via Phab
To decrease the number of false-positives, you could emit the warning only
if *exactly one* comma was missing.
const char *likely_a_bug[] = { "a", "b", "c" "d", "e", "f", "g", "h",
"i" };
const char *likely_not_a_bug[] = { "a", "b" "c", "d" "e", "f" "g" };
const char *oops_still_a_bug[
It looks to me as if all of the false-positives so far have been *not
arrays but structs*.
struct X { int a; const char *b; int c; };
X x = { 41, "forty" "two", 43 }; // false-positive here
The distinguishing feature here is that if you did insert a comma as
suggested by the compiler, then the r
Hi Dávid,
Does this part of the patch imply that we *don't *want to warn on
"foo" TWO
? and if so, why not?
Anyway, I think at least
"foo" TWO
should be kept in the test suite, as a test-for-absence-of-warning.
TWO "bar",
- "foo" TW
On Fri, Mar 27, 2020 at 8:16 PM Arthur O'Dwyer
wrote:
> Richard: Okay, filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94376 !
>
> David: You are correct, the bug in function_ref appeared only when
> constructing from `const function_ref&&`. When I said that the constructor
> template suppress
x27;const&&' constructor
W = nullptr;
ASSERT_EQ(LX(), 1);
}
–Arthur
On Fri, Mar 27, 2020 at 7:48 PM Richard Smith wrote:
> On Thu, 26 Mar 2020 at 21:50, Arthur O'Dwyer via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> [...]
>> Argh! Th
On Thu, Mar 26, 2020 at 11:49 PM Richard Smith
wrote:
> On Thu, 26 Mar 2020 at 17:07, David Blaikie via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Thu, Mar 26, 2020 at 3:12 PM Arthur O'Dwyer
>> wrote:
>>
>>> I'm not sure, but I do see that the call stack contains a call to
>>>
>>
I'm not sure, but I do see that the call stack contains a call to
bool llvm::function_ref::callback_fn
const>(long, clang::Expr*&, bool)
Notice that this is function_ref::callback_fn instantiated with
T=function_ref itself; i.e., we do have a function_ref to a function_ref.
This is the thing I wa
On Sun, Mar 22, 2020 at 1:48 PM David Blaikie via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> On Sun, Mar 22, 2020 at 10:40 AM Johannes Doerfert
> wrote:
>
>> Some buildbots, I think only Windows buildbots for some reason, crashed
>> in this function.
>>
>> The reason, as described, is tha
On Fri, Feb 28, 2020 at 11:23 AM James Y Knight via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> On Fri, Feb 28, 2020 at 10:05 AM Aaron Ballman
> wrote:
>
>> On Thu, Feb 27, 2020 at 6:04 PM James Y Knight
>> wrote:
>> >
>> > But, even with all that, I'm not sure why we shouldn't implement
I see your point about how users who care should always be passing this
check alongside "performance-move-const-arg"; but IMVHO it still makes
sense for clang-tidy to warn unconditionally about code of the form
x = std::move(y);
use(y);
regardless of the incidental type of `y`. Sure, it's
FWIW, I think it's a lot harder to make this kind of typo-bug if you always
(always!) keep all your numbers in number-line order, with all the
alligators' mouths opening to the right:
return CT_Vector *<*= CT && CT *<*= CT_ForwardList;
Some programming languages (not C++) even let you omit th
On Mon, Oct 7, 2019 at 6:58 PM Dávid Bolvanský
wrote:
>> FWIW I found the "always evaluates to 'true'" bit important to
>> understand the warning.
>
> Yeah. I moved this check somewhere else, so we can print precise message:
> r373973 should emit "bitwise negation of a boolean expression always
>
On Mon, Oct 7, 2019 at 10:59 AM Dávid Bolvanský via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Okey, I will see what I can do (I know I need to move checking code
> somewhere else).
>
> > Dňa 7. 10. 2019 o 16:54 užívateľ Nico Weber
> napísal:
> > FWIW I found the "always evaluates to 'tru
On Mon, Aug 19, 2019 at 1:53 PM Nico Weber via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Hi,
>
> this results in a false positive on webrtc, on this code:
>
>
> https://cs.chromium.org/chromium/src/third_party/libwebp/src/enc/picture_csp_enc.c?q=picture_csp_enc.c&sq=package:chromium&dr&l=
Peanut gallery says: I think the one remaining instance of `-std=libc++` in
the tests should be fixed at the same time.
–Arthur
On Sat, Nov 17, 2018 at 9:52 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Good idea, this LG for a patch release.
>
> On Sat, 17 Nov 2018, 18
On Thu, Jul 26, 2018 at 12:52 PM, Richard Smith
wrote:
> Other than the (fixed) ffmpeg false positive, I see this firing in three
> places.
>
> One of them is in the libc tests for memset and bzero, where the 0
> argument is intentional.
> One of them is here: https://github.com/apache/xerces-c/b
In this case Clang is complaining about
memset(complicated-expr, 0, 0);
which means that transposing the last two arguments would not "fix"
anything. Clang ought to not complain in this case.
It doesn't have anything to do with coming from a macro; it's just that
*both* arguments are zero.
(I
https://reviews.llvm.org/D47067 is a "Restricted Differential Revision",
which I've never seen before!
Peanut gallery says: This sounds awesome. How does this change interact
with the diagnostics issued by -Wpessimizing-move and -Wreturn-std-move?
Should any new test cases be added for those diagno
On Wed, Apr 25, 2018 at 7:10 PM, Richard Smith
wrote:
> On 23 April 2018 at 20:07, John McCall via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>>
>> The issue there is that -Wnoisy-in-tests is likely to be useful as a
>> cancellation of -Wno-noisy-in-tests, which (as David suggests) migh
On Mon, Oct 23, 2017 at 7:33 AM, Aaron Ballman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> On Mon, Oct 23, 2017 at 9:48 AM, Hal Finkel wrote:
> > On 10/21/2017 10:14 AM, Aaron Ballman via cfe-commits wrote:
> >>
> >> Attributes come with multiple spelling flavors, but when it comes to
On Thu, Nov 17, 2016 at 2:14 PM, Sasha Bermeister
wrote:
> Although I agree with your philosophical discussion and suggestions, the
> reality is that MSVC's behavior is not a bug and compilers are free to
> interpret enum bitfields with no explicit underlying type in any way they
> want (see spec
On Thu, Nov 17, 2016 at 9:52 AM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> On 17 Nov 2016 8:56 am, "Reid Kleckner" wrote:
>> In https://reviews.llvm.org/D24289#598169, @rsmith wrote:
>>> This is causing warnings to fire for headers shared between C and C++,
>>> where the
Quuxplusone added inline comments.
Comment at: test/CodeGen/no-devirt.cpp:16
@@ +15,3 @@
+ if (a > 6) return data[a] ; // Should not devirtualize
+ if (a > 4) return data.func1(a); // Should devirtualize
+ return data.func2(a);// Should devirtualize
Quuxplusone added a subscriber: Quuxplusone.
Comment at: test/CodeGen/no-devirt.cpp:16
@@ +15,3 @@
+ if (a > 6) return data[a] ; // Should not devirtualize
+ if (a > 4) return data.func1(a); // Should devirtualize
+ return data.func2(a);// Should devirtualiz
Given that this patch is basically Chandler's talk from CppCon 2015 (
https://www.youtube.com/watch?v=nXaxk27zwlk), I'm surprised that the commit
message isn't explicitly mentioning that; and surprised that Chandler
himself isn't weighing in on either the "this is a good idea" or "this is a
bad ide
On Wed, Jun 1, 2016 at 7:00 PM, Eric Fiselier wrote:
> No the leak was my fault. The sneaky line was "std::shared_ptr s(ptr,
> &nullDeleter);", which caused the allocation of a shared control block.
>
But surely the control block is allocated and deallocated by libc++ behind
the scenes, foolproo
I don't get it. If this code doesn't pass ASAN, or if it leaks anything,
doesn't that indicate a bug in the library implementation of C++1z
shared_ptr? I can't find where this code does anything sneaky that a
sanitizer ought to care about...
On Jun 1, 2016 6:15 PM, "Eric Fiselier via cfe-commits" <
Quuxplusone added a subscriber: Quuxplusone.
Quuxplusone added a comment.
It seems like this proposed diagnostic and fixit, statistically speaking, is
*never* correct.
In the cases where there is a code issue to be corrected, the diagnosable issue
really seems to involve dataflow analysis:
"Her
On Wed, May 4, 2016 at 1:43 PM, Aaron Ballman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> jbcoe wrote:
> > aaron.ballman wrote:
> > > I believe we use "modernize" to really mean "migrate from the old way
> to the new way", which this definitely fits into since I think the point to
> thi
Quuxplusone added a subscriber: Quuxplusone.
Quuxplusone added a comment.
I would like to see a new version of http://reviews.llvm.org/D19105 with all
the "1-bit-bitfield" diffs removed.
Right now, it's hard to see that there's *anything* in
http://reviews.llvm.org/D19105 that's not a miscorrect
I'm not qualified to comment on the implementation, but I'm a bit skeptical
that this warning is appropriate in the first place. I've often declared
friend non-template functions, e.g. swap(). I've never intended to declare
a friend *template specialization*. Is declaring friend template
specializa
Following Louis' suggestion, how about __pack_nth?
On Wed, Jan 13, 2016 at 3:16 PM, Nathan Wilson via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
>
> On Wed, Jan 13, 2016 at 4:52 PM, Richard Smith
> wrote:
>
>> On Wed, Jan 13, 2016 at 2:31 PM, Nathan Wilson
>> wrote:
>>
>>> nwilson added
55 matches
Mail list logo