I have a different problem. clang is complaining on the 4.1 back port of a patch which is merged in master before clang-format is brought in. Is there a way I can get smoke +1 for 4.1 as it won't be neat to have clang changes in 4.1 and not in master for same patch. It might further affect the clean back ports.
- Kotresh HR On Tue, Sep 18, 2018 at 2:13 PM, Ravishankar N <ravishan...@redhat.com> wrote: > > > On 09/18/2018 02:02 PM, Hari Gowtham wrote: > >> I see that the procedure mentioned in the coding standard document is >> buggy. >> >> git show --pretty="format:" --name-only | grep -v "contrib/" | egrep >> "*\.[ch]$" | xargs clang-format -i >> >> The above command edited the whole file. which is not supposed to happen. >> > It works fine on fedora 28 (clang version 6.0.1). I had the same problem > you faced on fedora 26 though, presumably because of the older clang > version. > -Ravi > > > >> +1 for the readability of the code having been affected. >> On Mon, Sep 17, 2018 at 10:45 AM Amar Tumballi <atumb...@redhat.com> >> wrote: >> >>> >>> >>> On Mon, Sep 17, 2018 at 10:00 AM, Ravishankar N <ravishan...@redhat.com> >>> wrote: >>> >>>> >>>> On 09/13/2018 03:34 PM, Niels de Vos wrote: >>>> >>>>> On Thu, Sep 13, 2018 at 02:25:22PM +0530, Ravishankar N wrote: >>>>> ... >>>>> >>>>>> What rules does clang impose on function/argument wrapping and >>>>>> alignment? I >>>>>> somehow found the new code wrapping to be random and highly >>>>>> unreadable. An >>>>>> example of 'before and after' the clang format patches went in: >>>>>> https://paste.fedoraproject.org/paste/dC~aRCzYgliqucGYIzxPrQ >>>>>> Wondering if >>>>>> this is just me or is it some problem of spurious clang fixes. >>>>>> >>>>> I agree that this example looks pretty ugly. Looking at random changes >>>>> to the code where I am most active does not show this awkward >>>>> formatting. >>>>> >>>> >>>> So one of my recent patches is failing smoke and clang-format is >>>> insisting [https://build.gluster.org/job/clang-format/22/console] on >>>> wrapping function arguments in an unsightly manner. Should I resend my >>>> patch with this new style of wrapping ? >>>> >>>> I would say yes! We will get better, by changing options of >>> clang-format once we get better options there. But for now, just following >>> the option suggested by clang-format job is good IMO. >>> >>> -Amar >>> >>> Regards, >>>> Ravi >>>> >>>> >>>> >>>> However, I was expecting to see enforcing of the >>>>> single-line-if-statements like this (and while/for/.. loops): >>>>> >>>>> if (need_to_do_it) { >>>>> do_it(); >>>>> } >>>>> >>>>> instead of >>>>> >>>>> if (need_to_do_it) >>>>> do_it(); >>>>> >>>>> At least the conversion did not take care of this. But, maybe I'm wrong >>>>> as I can not find the discussion in https://bugzilla.redhat.com/15 >>>>> 64149 >>>>> about this. Does someone remember what was decided in the end? >>>>> >>>>> Thanks, >>>>> Niels >>>>> >>>> >>>> >>> >>> -- >>> Amar Tumballi (amarts) >>> _______________________________________________ >>> Gluster-devel mailing list >>> Gluster-devel@gluster.org >>> https://lists.gluster.org/mailman/listinfo/gluster-devel >>> >> >> >> > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-devel > -- Thanks and Regards, Kotresh H R
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel