Re: [PATCH] D123345: Treat `std::move`, `forward`, and `move_if_noexcept` as builtins.

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

[clang] f0891cd - [clang] [concepts] Check constrained-auto return types for void-returning functions

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:

[clang] adf6703 - [clang] [NFC] Add `const` to a parameter that's not modified.

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:

[clang] d3db74e - [clang] Remove unused variable AllElementsInt.

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:

Re: [PATCH] D119670: [clang] Warn on unqualified calls to std::move and std::forward

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>

[clang] 7adb858 - [clang] [NFC] More exhaustive tests for deducing void return types

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:

[clang] 597f2bc - [clang] [test] [NFC] Eliminate some hard tabs in tests

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:

[clang] 3c8d2aa - [clang] Don't emit redundant warnings for 'return; '

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:

[clang] 528deed - [clang] [test] Fix an apparent typo in SemaCXX/consteval-return-void.cpp.

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:

[clang] c0185ff - [clang] Don't typo-fix an expression in a SFINAE context.

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:

[clang] f6ce456 - [clang] Correctly(?) handle placeholder types in ExprRequirements.

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:

[clang] 424400d - [clang][NFC] Change some ->getType()->isPlaceholderType() to just ->hasPlaceholderType()

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:

[clang] f9a00b3 - Revert "[clang] Don't typo-fix an expression in a SFINAE context."

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:

[clang] 9be5f4d - [clang] Don't typo-fix an expression in a SFINAE context.

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:

Re: RFC: proposing to relax standardization requirements for Clang extensions

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

[clang] 2b4cad5 - [clang] Enable the special enable_if_t diagnostics for libc++'s __enable_if_t as well.

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:

[clang] 5f1de9c - [C++20] [P1825] Fix bugs with implicit-move from variables of reference type.

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:

[clang] fbee4a0 - [C++20] [P1825] More implicit moves

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

[clang] 22cf54a - Replace `T(x)` with `reinterpret_cast(x)` everywhere it means reinterpret_cast. NFC.

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:

[clang] e181a6a - s/instantate/instantiate/ throughout. NFCI.

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:

[clang-tools-extra] e181a6a - s/instantate/instantiate/ throughout. NFCI.

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:

[clang] 703038b - [Sema] Fix volatile check when testing if a return object can be implicitly moved

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

Re: [PATCH] D85545: [Diagnostics] Diagnose missing comma in string array initialization

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

Re: [PATCH] D85545: [Diagnostics] Diagnose missing comma in string array initialization

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

Re: [PATCH] D85545: [Diagnostics] Diagnose missing comma in string array initialization

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

Re: [clang] 975467e - [Diagnostics] Handle string concat pattern and avoid false positives

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"

Re: [clang] 857bf5d - [FIX] Do not copy an llvm::function_ref if it has to be reused

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

Re: [clang] 857bf5d - [FIX] Do not copy an llvm::function_ref if it has to be reused

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! That is insanely sneaky, and it is quite probable IM

Re: [clang] 857bf5d - [FIX] Do not copy an llvm::function_ref if it has to be reused

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 >>>

Re: [clang] 857bf5d - [FIX] Do not copy an llvm::function_ref if it has to be reused

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

Re: [clang] 857bf5d - [FIX] Do not copy an llvm::function_ref if it has to be reused

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

Re: [clang] d930ed1 - Disallow use of __has_c_attribute in C++ mode.

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

Re: [PATCH] D74692: [clang-tidy] Make bugprone-use-after-move ignore std::move for const values

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,

Re: [PATCH] D69292: Proposal to add -Wtautological-compare to -Wall

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

Re: r373743 - [NFCI] Improve the -Wbool-operation's warning message

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 >

Re: r369217 - [Diagnostics] Diagnose misused xor as pow

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=package:chromium=1002 >

Re: r341697 - warn_stdlibcxx_not_found: suggest '-stdlib=libc++' instead of '-std'

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,

Re: r337470 - [Sema] Add a new warning, -Wmemset-transposed-args

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:

Re: r337470 - [Sema] Add a new warning, -Wmemset-transposed-args

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.

Re: [PATCH] D47067: Update NRVO logic to support early return

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

Re: [PATCH] D45766: [Sema] Add -Wno-self-assign-overloaded

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

Re: Attribute spelling policy

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

Re: [PATCH] D24289: Add warning when assigning enums to bitfields without an explicit unsigned underlying type

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

Re: [PATCH] D24289: Add warning when assigning enums to bitfields without an explicit unsigned underlying type

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

Re: [PATCH] D22057: Prevent devirtualization of calls to un-instantiated functions.

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

Re: [PATCH] D22057: Prevent devirtualization of calls to un-instantiated functions.

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

Re: [libcxx] r271459 - Remove enable_shared_from_this test since it leaks the control block and fails with ASAN

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, > );", which caused the allocation of a shared control block. > But surely the control block is allocated and deallocated by libc++ behind the scenes,

Re: [libcxx] r271459 - Remove enable_shared_from_this test since it leaks the control block and fails with ASAN

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"

Re: [PATCH] D19105: Changes in clang after running http://reviews.llvm.org/D18821

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:

Re: [PATCH] D16962: clang-tidy: avoid std::bind

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 >

Re: [PATCH] D18821: Add modernize-bool-to-integer-conversion

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

Re: [PATCH] D16579: Warn if friend function depends on template parameters.

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