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- Kotresh HR
On Tue, Sep 18, 2018 at 2:13 PM, Ravishankar N <ravishankar@xxxxxxxxxx> wrote:
On 09/18/2018 02:02 PM, Hari Gowtham wrote:
I see that the procedure mentioned in the coding standard document is buggy.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.
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.
-Ravi
+1 for the readability of the code having been affected.
On Mon, Sep 17, 2018 at 10:45 AM Amar Tumballi <atumball@xxxxxxxxxx> wrote:
On Mon, Sep 17, 2018 at 10:00 AM, Ravishankar N <ravishankar@xxxxxxxxxx> wrote:
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.
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? II agree that this example looks pretty ugly. Looking at random changes
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.
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 ?
-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/1564149
about this. Does someone remember what was decided in the end?
Thanks,
Niels
--
Amar Tumballi (amarts)
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-devel
--
Thanks and Regards,
Kotresh H R_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-devel
