similar to: Modernizing LLVM Coding Style Guide and enforcing Clang-tidy

I'm a bit confused by this whole discussion. clang-format is neither mandated (by documentation) nor enforced (by any infrastructure/automation) for use in the LLVM project that I know of. It's convenient, and in review people may reasonably ask authors to consider running it, etc - but we have no system that requires or checks for that. Might be nice, might not be. It sounds like even

> > > From yesterday discussion, Daniel Berlin proposed using emplace_back > everywhere to make code easier to maintain. I think it is valid argument, > but I believe it would reduce readability. > Just to be clear; I proposed not trying to switch uses back and forth without real data, and to come to some agreement about what should be written in the first place, preferably

> On Dec 29, 2016, at 11:20 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Dec 29, 2016 at 10:04 AM Mehdi Amini via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: >> On Dec 29, 2016, at 5:54 AM, Daniel Berlin <dberlin at dberlin.org <mailto:dberlin at dberlin.org>> wrote: >> >>

On Thu, Dec 29, 2016 at 11:46 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > On Dec 29, 2016, at 11:20 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Dec 29, 2016 at 10:04 AM Mehdi Amini via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > > On Dec 29, 2016, at 5:54 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > >

On Thu, Dec 29, 2016 at 10:04 AM Mehdi Amini via cfe-dev < cfe-dev at lists.llvm.org> wrote: > On Dec 29, 2016, at 5:54 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > From yesterday discussion, Daniel Berlin proposed using emplace_back > everywhere to make code easier to maintain. I think it is valid argument, > but I believe it would reduce readability.

> On Dec 29, 2016, at 5:54 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > From yesterday discussion, Daniel Berlin proposed using emplace_back everywhere to make code easier to maintain. I think it is valid argument, but I believe it would reduce readability. > > Just to be clear; I proposed not trying to switch uses back and forth without real data, and to come

Somewhat unfortunately, we have two discussions here: - Clang-tidy has checks that might improve code -- should we deploy them? If so which? I'll address this in a separate email, and focus this one on: - Should we have coding standards around 'push_back' and 'emplace_back', and if so, what should they say? I think the amount of confusion makes a coding standard useful. As

Dave pointed out that I didn't complete one aspect of my argument on the push_back vs. emplace_back: On Thu, Dec 29, 2016 at 2:04 PM Chandler Carruth <chandlerc at gmail.com> wrote: > Still another way to see the consequence of this is to look at the nature > of compiler errors when a programmer makes a mistake. > > With emplace_back, if you fail to call the constructor

Thanks for very accurate responses. - I totally agree what Dave and Chandler said about explicit and implicit operations, this is what I meant my first email. I believe there are places like v.emplace_back(A, B); istead of v.push_back(make_pair(A, B));b That can make code simpler. I think in cases like this we can leave it for judgement of contributor. Having said that I think the

2016-12-30 11:34 GMT+01:00 Chandler Carruth <chandlerc at gmail.com>: > On Fri, Dec 30, 2016 at 2:08 AM Piotr Padlewski via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Thanks for very accurate responses. >> - I totally agree what Dave and Chandler said about explicit and implicit >> operations, this is what I meant my first email. >> I believe

On Fri, Dec 30, 2016 at 2:08 AM Piotr Padlewski via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Thanks for very accurate responses. > - I totally agree what Dave and Chandler said about explicit and implicit > operations, this is what I meant my first email. > I believe there are places like > v.emplace_back(A, B); > istead of > v.push_back(make_pair(A,

On Mon, Jan 9, 2017 at 6:17 AM Piotr Padlewski via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Are there any other comments about changing style guide? > I would like to add points like > > - prefer "using' instead of "typedef" > - use default member initialization > struct A { > void *ptr = nullptr; > }; > > (instead of doing it in

On 9 January 2017 at 14:17, Piotr Padlewski via cfe-dev <cfe-dev at lists.llvm.org> wrote: > - prefer "using' instead of "typedef" > - use default member initialization > - use default, override, delete > - skip "virtual" with override I thought we had all of those already... > The last point is to get to consensus with > >

The upcoming C++1z (probably C++17) standard will not contain several things - most notably auto_ptr. Soon, libc++ will not be providing auto_ptr by default when building in C++1z mode. You'll be able to get it back with a "-D_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR" on your command line, or "#define _LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR" before including any libc++ header

> On Jan 9, 2017, at 12:47 PM, Renato Golin <renato.golin at linaro.org> wrote: > > On 9 January 2017 at 19:04, Mehdi Amini <mehdi.amini at apple.com> wrote: >> This is not correct according to the number of “should” and the imperative tone for many aspects of http://llvm.org/docs/CodingStandards.html#source-code-formatting > > You mistake the tone of the

> On Jan 9, 2017, at 10:29 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 9 January 2017 at 18:20, Reid Kleckner <rnk at google.com> wrote: >> I object to the first. If you need a new type name, use a typedef. It's time >> honored and everyone, including C programmers, will know what you're doing. >> I don't understand

LLVM Weekly - #130, Jun 27th 2016 ================================= If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/130>. Welcome to the one hundred and thirtieth issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex

+100 to Mehdi. Large scale cleanups should not only be welcome, they should be encouraged. This is the type of work that almost nobody wants to do and is sorely underappreciated (as evidenced by the fact that this thread even exists, IMHO). Code quality and code health are ongoing costs, and if we raise the barrier to entry for this type of change, then they're not going to happen. Why

On Fri, Apr 7, 2017 at 3:14 PM Adrian Prantl <aprantl at apple.com> wrote: > > > On Apr 7, 2017, at 3:05 PM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > There have been some efforts recently to use clang-tidy or similar > automated refactoring to make project-wide cleanups/improvements to the > LLVM codebase that appear to me

Hi, all, I am planning to add clang-tidy checkers for my company. How to add a new module for my company? Please help, thanks in advance. I try to copy files from cert module, and rename cert to Misra, then add a rule named "m-0-1-1" by ./add_new_checker.py. then I run ninja check-clang-tool, but my case is failed due to below error Running ['clang-tidy',