Hi all,
You can stop reading, if you have a setup that never requires you to
applying clang-format manually. (Aside: For those that eagerly want to
belong to this group, but don't yet, I suggest you look into `./mach ide`.)
For all those who get the clang-format warning from code-review bo
h are the guidelines that should apply only
> > to older code?
> >
> > "we are not aiming to enforce any naming conventions at this time"
> > [1] but both the Google and Mozilla style guides have
> > (conflicting) naming conventions. Can we clarify which, i
ing
this in large projects that adopt the Google C++ Style (e.g. the Chromium
C++ Style
https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md
).
> The other piece of the equation here is [1]
> > our precise coding style will be the result of formatting our
>
an we distinguish which are the guidelines that should apply only
> to older code?
>
> "we are not aiming to enforce any naming conventions at this time"
> [1] but both the Google and Mozilla style guides have
> (conflicting) naming conventions. Can we clarify which, if any,
uidelines apply to new and older code?
The other piece of the equation here is [1]
> our precise coding style will be the result of formatting our
> tree with clang-format, so by definition our code, when
> formatted with clang-format, will be following our new coding
> style.
clang-
We have now clang format hooks/extension for hg and git.
Both work in the same way: at commit phase, they will automatically run
"mach clang-format
<https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style/Formatting_C++_Code_With_clang-format>"
(which is
27;d like to propose the first modification to our clang-format rules based
> on the feedback I've received since the switch to our new coding style from
> the SpiderMonkey team.
>
> The problem we're trying to solve is that in code that has nested
> preprocessor directives,
On 11/01/19 02:01, Ehsan Akhgari wrote:
> The common way to deal with this problem is to indent nested preprocessor
> directives, very much similarly to how we indent normal code, for example:
>
> #if foo
> # if bar
> #define x 1
> # else
> #define x 2
> # endif
> #endif
this would be
This has been my preferred style for a long time, but lately
clang-format just throws it away whenever I try to do it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Hi everyone,
I'd like to propose the first modification to our clang-format rules based
on the feedback I've received since the switch to our new coding style from
the SpiderMonkey team.
The problem we're trying to solve is that in code that has nested
preprocessor direc
On Wed, Dec 5, 2018 at 5:51 AM Ehsan Akhgari
wrote:
> On Fri, Nov 30, 2018 at 8:23 PM Ehsan Akhgari
> wrote:
>
>> On Fri, Nov 30, 2018 at 4:08 PM Gregory Szorc wrote:
>>
>>> On Fri, Nov 30, 2018 at 10:00 AM wrote:
>>>
>>> > Now that all of m
On Fri, Nov 30, 2018 at 8:23 PM Ehsan Akhgari
wrote:
> On Fri, Nov 30, 2018 at 4:08 PM Gregory Szorc wrote:
>
>> On Fri, Nov 30, 2018 at 10:00 AM wrote:
>>
>> > Now that all of mozilla-central is been migrated to use clang-format
>> > automated code for
On Fri, Nov 30, 2018 at 4:08 PM Gregory Szorc wrote:
> On Fri, Nov 30, 2018 at 10:00 AM wrote:
>
> > Now that all of mozilla-central is been migrated to use clang-format
> > automated code formatting, the question of what should happen with editor
> > modelines at th
On Fri, Nov 30, 2018 at 2:06 PM Nathan Froyd wrote:
> On Fri, Nov 30, 2018 at 1:51 PM Ehsan Akhgari
> wrote:
> > I think these are all great points. It seems like for Emacs, it is not
> > actually necessary to sprinkle modelines across all of the files in your
> > repository (per https://bugzil
On Fri, Nov 30, 2018 at 09:57:00AM -0800, tcampb...@mozilla.com wrote:
> Now that all of mozilla-central is been migrated to use clang-format
> automated code formatting, the question of what should happen with editor
> modelines at the top of files should be considered.
&
On Fri, Nov 30, 2018 at 10:00 AM wrote:
> Now that all of mozilla-central is been migrated to use clang-format
> automated code formatting, the question of what should happen with editor
> modelines at the top of files should be considered.
>
> https://bugzilla.mozilla.org/show_b
Nathan> Unfortunately, it doesn't look like .dir-locals.el provides any way to
Nathan> set file modes, e.g. setting python-mode for moz.build file
That's correct, it's a hole in dir-locals (there's already a bug filed
against Emacs for this). It's also easy to document how to update
auto-mode-ali
On Fri, Nov 30, 2018 at 1:51 PM Ehsan Akhgari wrote:
> I think these are all great points. It seems like for Emacs, it is not
> actually necessary to sprinkle modelines across all of the files in your
> repository (per https://bugzilla.mozilla.org/show_bug.cgi?id=1023839#c7).
> For Vim, Benjamin
On Fri, Nov 30, 2018 at 10:00 AM wrote:
> Now that all of mozilla-central is been migrated to use clang-format
> automated code formatting, the question of what should happen with editor
> modelines at the top of files should be considered.
>
> https://bugzilla.mozilla.org/show_b
On Fri, Nov 30, 2018 at 1:00 PM wrote:
> Now that all of mozilla-central is been migrated to use clang-format
> automated code formatting, the question of what should happen with editor
> modelines at the top of files should be considered.
>
> https://bugzilla.mozilla.org/show_b
Now that all of mozilla-central is been migrated to use clang-format automated
code formatting, the question of what should happen with editor modelines at
the top of files should be considered.
https://bugzilla.mozilla.org/show_bug.cgi?id=clang-format
Here are some options and some arguments
Now instead we will get to try to phrase code in a way that
clang-format will preserve readably?
I should think "it doesn't always produce nice formatting, but it's at
least consistent" sounds like a major warning sign, particularly given
that we definitely have tricky code fo
Le 28/09/2017 à 23:21, Randell Jesup a écrit :
>> On Thursday, September 28, 2017 at 10:15:05 AM UTC+2, Chris Pearce wrote:
>> Oh d'oh! Looks like I replied to an old thread, and the plan now is in fact
>> to clang-format the entire tree after 57. Sweet as!
> Where di
>On Thursday, September 28, 2017 at 10:15:05 AM UTC+2, Chris Pearce wrote:
>Oh d'oh! Looks like I replied to an old thread, and the plan now is in fact
>to clang-format the entire tree after 57. Sweet as!
Where did you find that? Was this plan communicated? It's not in th
On Thursday, September 28, 2017 at 10:15:05 AM UTC+2, Chris Pearce wrote:
> On Friday, May 23, 2014 at 3:29:48 AM UTC+2, Anthony Jones wrote:
> > Some of you may remember the discussion on clang-format and the `mach
> > clang-format` command. What we have in place right now is
On Friday, May 23, 2014 at 3:29:48 AM UTC+2, Anthony Jones wrote:
> Some of you may remember the discussion on clang-format and the `mach
> clang-format` command. What we have in place right now is very temporary
> but it is functional enough to give it a try. I have not put the effo
On Wed, Sep 27, 2017 at 7:34 AM, Mike Hommey wrote:
> And then you end up with something like:
>
> class Foo {
> Type MethodA() { do_something(); }
> Type MethodB()
> {
> do_something_that_happens_to_be_long_enough_not_to_fit_on_the_same_line();
> }
> Type MethodC() { do_something_el
On Tue, Sep 26, 2017 at 10:49 PM, Sylvestre Ledru
wrote:
>> clang-format messes up really badly many macros.
>> For example nsElementTable.cpp becomes unreadable.
>
> Yeah, for this kind of structure & presentation layout, we should just
ignore the formatting on the
On Tue, Sep 26, 2017 at 02:49:56PM +0200, Sylvestre Ledru wrote:
> Le 26/09/2017 à 14:33, smaug a écrit :
> > On 05/23/2014 04:29 AM, Anthony Jones wrote:
> >> Some of you may remember the discussion on clang-format and the `mach
> >> clang-format` command. What we have
Le 26/09/2017 à 14:33, smaug a écrit :
> On 05/23/2014 04:29 AM, Anthony Jones wrote:
>> Some of you may remember the discussion on clang-format and the `mach
>> clang-format` command. What we have in place right now is very temporary
>> but it is functional enough to give it
On 05/23/2014 04:29 AM, Anthony Jones wrote:
Some of you may remember the discussion on clang-format and the `mach
clang-format` command. What we have in place right now is very temporary
but it is functional enough to give it a try. I have not put the effort
into upstreaming my changes
On 22/05/2014 18:29, Anthony Jones wrote:
> Some of you may remember the discussion on clang-format and the `mach
> clang-format` command. What we have in place right now is very temporary
> but it is functional enough to give it a try. I have not put the effort
> into upstreamin
I tried using clang-format on entire files and I noticed two things
(there might be others, I didn't look too closely):
1) When it reformats comments to fit in the line length, it just inserts
linebreaks rather than rewrapping the text. So you end
up
with text like this, where the last c
Some of you may remember the discussion on clang-format and the `mach
clang-format` command. What we have in place right now is very temporary
but it is functional enough to give it a try. I have not put the effort
into upstreaming my changes. Depending on the feedback I receive I will
either
On 23/01/14 15:26, Gregory Szorc wrote:
> As a temporary workaround until upstream gets patched, we're
> downloading and running hosted binaries from ajone's people account
> (with consent of course). He hasn't built the binary for OS X yet.
I've created bug 962954 to track this issue.
Anthony
__
952379 has landed on m-c so you can now use the work flow below:
>>
>> $ hg qrefresh
>> $ mach clang-format
>>
>> This reformats only the lines that are different from tip^. It doesn't
>> show anything on the console. Review the changes with your favourite
>
n now use the work flow below:
>
> $ hg qrefresh
> $ mach clang-format
>
> This reformats only the lines that are different from tip^. It doesn't
> show anything on the console. Review the changes with your favourite
> diff tool. You can see a beautiful screenshot here:
&g
Excuse the continued conversation with myself.
Bug 952379 has landed on m-c so you can now use the work flow below:
$ hg qrefresh
$ mach clang-format
This reformats only the lines that are different from tip^. It doesn't
show anything on the console. Review the changes with your favo
clang-format-3.5 is now available for Windows using the updated patch in
bug 952379.
Anthony
On 08/01/14 15:31, Anthony Jones wrote:
> I have been doing some testing with clang-format and formatting only the
> lines that have been modified.
>
> Version 3.5 is good enough for M
I have been doing some testing with clang-format and formatting only the
lines that have been modified.
Version 3.5 is good enough for Mozilla style although the defaults for
style=Mozilla need to be corrected. It doesn't handle weird cases like
NS_IMPL_CYCLE_COLLECTION_UNLINK_BEGIN and
On Sun, May 05, 2013 at 04:04:44PM -0400, Ehsan Akhgari wrote:
> clang-format is a source code formatting tool developed by Google which can
> do automatic whitespace cleanup, vertical alignment and line breaking
> changes to C++ code. See this video [1] for a recent presentation about
&
clang-format is a source code formatting tool developed by Google which can
do automatic whitespace cleanup, vertical alignment and line breaking
changes to C++ code. See this video [1] for a recent presentation about
the tool in the LLVM Developers Conference (the slides are here [2]). And
it
42 matches
Mail list logo
