Quick update.
It looks like clang-format is actually okay with C-style comments being on
their own line before a method definition. So last night patches landed to move
all these comments to their own line.
From:
/* static */ void Foo::Bar() { ... }
To:
/* static */
void Foo::Bar() { ... }
So
On 1/30/19 10:19 AM, Ehsan Akhgari wrote:
What tool do you use which has difficulty showing function names in diffs
right now? It seems to work fine for me both in git and hgweb...
"hg diff" and "git diff" both fail at this over here when there is a /*
comment */ before the function name.
Ehsan Akhgari writes:
> What tool do you use which has difficulty showing function names in diffs
> right now? It seems to work fine for me both in git and hgweb...
It's cases like these that are truncated earlier due to putting
the return type before the function name:
% hg export
I've filed bug 1523969 to consider making this change.
(https://bugzilla.mozilla.org/show_bug.cgi?id=1523969)
‐‐‐ Original Message ‐‐‐
On Monday, January 28, 2019 6:27 PM, Ryan Hunt wrote:
> Yeah, personally I have found them be useful and don't have an issue with
> keeping
> them. I
On Wed, Jan 30, 2019 at 1:35 AM Karl Tomlinson wrote:
> Ehsan Akhgari writes:
>
> > On Mon, Jan 28, 2019 at 2:58 PM Jeff Gilbert
> wrote:
> >
> >> I would much rather revert to:
> >> /*static*/ void
> >> Foo::Bar()
> >>
> >> The Foo::Bar is the most relevant part of that whole expression, which
On Wed, Jan 30, 2019 at 1:30 AM Karl Tomlinson wrote:
> Ehsan Akhgari writes:
>
> > On Mon, Jan 28, 2019 at 6:27 PM Ryan Hunt wrote:
> >
> >> [...]
> >>
> >> So for converting from C-style to C++-style, that would be:
> >>
> >> /* static */ void Foo::Bar() {
> >> ...
> >> }
> >>
> >> // static
On Tue, Jan 29, 2019 at 6:40 PM wrote:
> On Wednesday, January 30, 2019 at 9:57:02 AM UTC+11, Ehsan Akhgari wrote:
> > On Mon, Jan 28, 2019 at 7:10 PM wrote:
> >
> > > Just a thought: Would it be worth considering a blank macro, e.g.:
> > > static void foo();
> > > DECLARED_STATIC void foo()
Ehsan Akhgari writes:
> On Mon, Jan 28, 2019 at 2:58 PM Jeff Gilbert wrote:
>
>> I would much rather revert to:
>> /*static*/ void
>> Foo::Bar()
>>
>> The Foo::Bar is the most relevant part of that whole expression, which
>> makes it nice to keep up against the start of the line.
>>
>
> The
Ehsan Akhgari writes:
> On Mon, Jan 28, 2019 at 6:27 PM Ryan Hunt wrote:
>
>> [...]
>>
>> So for converting from C-style to C++-style, that would be:
>>
>> /* static */ void Foo::Bar() {
>> ...
>> }
>>
>> // static
>> void Foo::Bar() {
>> ...
>> }
>>
>> [...]
>>
>> My one concern would be the
On Wednesday, January 30, 2019 at 9:57:02 AM UTC+11, Ehsan Akhgari wrote:
> On Mon, Jan 28, 2019 at 7:10 PM wrote:
>
> > Just a thought: Would it be worth considering a blank macro, e.g.:
> > static void foo();
> > DECLARED_STATIC void foo() {...}
> >
> > On top of not being confused with other
On Mon, Jan 28, 2019 at 7:10 PM wrote:
> Just a thought: Would it be worth considering a blank macro, e.g.:
> static void foo();
> DECLARED_STATIC void foo() {...}
>
> On top of not being confused with other comments around, it could be
> clang-checked so it's never wrong. (And maybe eventually
On Mon, Jan 28, 2019 at 2:58 PM Jeff Gilbert wrote:
> I would much rather revert to:
> /*static*/ void
> Foo::Bar()
>
> The Foo::Bar is the most relevant part of that whole expression, which
> makes it nice to keep up against the start of the line.
>
The clang-format option which allows
On Mon, Jan 28, 2019 at 6:27 PM Ryan Hunt wrote:
> Yeah, personally I have found them be useful and don't have an issue with
> keeping
> them. I just wasn't sure if that was a common experience.
>
> So for converting from C-style to C++-style, that would be:
>
> /* static */ void Foo::Bar() {
>
Just a thought: Would it be worth considering a blank macro, e.g.:
static void foo();
DECLARED_STATIC void foo() {...}
On top of not being confused with other comments around, it could be
clang-checked so it's never wrong. (And maybe eventually enforced, like
MOZ_IMPLICIT is.)
Cheers,
Gerald
Yeah, personally I have found them be useful and don't have an issue with
keeping
them. I just wasn't sure if that was a common experience.
So for converting from C-style to C++-style, that would be:
/* static */ void Foo::Bar() {
...
}
// static
void Foo::Bar() {
...
}
I think that would
I would much rather revert to:
/*static*/ void
Foo::Bar()
The Foo::Bar is the most relevant part of that whole expression, which
makes it nice to keep up against the start of the line.
In a clang-format world, we should feel more free to make such
deviations from Google Style, since it's all
This is indeed one of the cases where the reformat has made things worse.
I think as a couple of people have already said, we'll find that some
people do find these annotations useful, even if they're not always
consistently present.
The path to least resistance for addressing this problem may be
I find them extremely useful, too (as in "removing them would make my
life miserable in quite a few bugs"). I have no problem with putting
them on a separate line.
Cheers,
David
On 26/01/2019 15:19, Jonathan Watt wrote:
> Personally I find them useful. Putting them on a separate line seems
>
Personally I find them useful. Putting them on a separate line seems reasonable
to me.
Jonathan
On 26/01/2019 04:49, Ryan Hunt wrote:
> Hi all,
>
> Quick C++ style question.
>
> A common pattern in Gecko is for method definitions to have a comment with the
> 'static' or 'virtual'
Hi all,
Quick C++ style question.
A common pattern in Gecko is for method definitions to have a comment with the
'static' or 'virtual' qualification.
Before the reformat, the comment would be on it's own separate line [1]. Now
it's on the main line of the definition [2].
For example:
/*
20 matches
Mail list logo
