Subject: Re: bug#73182: CC Mode 5.35.2 (C++//l); 'enum' and 'enum class' appear to not get parsed correctly for indentation

From: Alan Mackenzie <[email-masked]>
Date: Tue, 17 Sep 2024 20:30:58 +0000

Hello again, Arsen.

On Tue, Sep 17, 2024 at 12:43:05 +0200, Arsen Arsenović wrote:
> Hi Alan,

> Alan Mackenzie <[email-masked]> writes:

> > Thanks for taking the trouble to raise this bug report last Wednesday.

> > On Wed, Sep 11, 2024 at 20:52:15 +0200, Arsen Arsenović via CC-Mode-help wrote:
> >> Package: cc-mode

> >> <#secure method=pgpmime mode=sign>
> >> Package: cc-mode

> >> Hi again,

> >> CC-mode appears to misindent enum and enum class:

> >>   enum asda
> >>     {
> >>       asd
> >>     };

> >>   enum class asasdas
> >>     {
> >>       asda
> >>     };

> > Yes.

> >> These should be indented same as struct per
> >> https://www.gnu.org/prep/standards/html_node/Formatting.html#index-enum-types_002c-formatting
> >> (well, enum class isn't mentioned, but I see no reason to act different,
> >> and GCC appears to do this, so it'd be convenient to keep struct-like
> >> formatting).

> > Yes.

> >> When using C-c C-s, it appears that C and C++ mode do not even recognize
> >> enum as a class-open, instead doing brace-list-open.

> > Yes.  This bug has come up at least once before, on 19 February 2014, in a
> > post to [email-masked] from Xue Fuqiao, Subject: CC Mode 5.32.5
> > (C/l); The indentation of `enum' of the default `gnu' style is wrong?
> > After having considered the matter for some time, I answered on 3 March
> > 2014 as follows:

> >     Even though there's a bug, it's been there for a _very_ long time
> >     (since before 1997), such a long time that it would cause chaos if
> >     it were to be fixed.  You can see many examples of this wrong enum
> >     indentation all through the Emacs C source, and probably throughout
> >     the entire GNU project.

> >     If this bug were to be fixed, inconsistent (even if correct)
> >     indentation would start creeping into thousands of files.  I think
> >     it's best left as it is, unsatisfactory though that be.

> As a data point here, the correct indentation is present all over GCC
> (which has people using everything from vi over notepad++ to VScode, and
> naturally, Emacs), but it is mixed up, presumably partially as a result
> of this bug, so I'd prefer if the editor would DTRT OOTB.

Thanks.  I've just written a little AWK script to count occurrences of
the "standard" indentation (the opening brace directly under enum in
column 0) and "non-standard" indentation (the opening brace indented
under enum in column 0).  The results have surprised me somewhat.

In "my" version of gcc-13.3.1, there are 947 standard indentations and 81
non-standard.  Even in the Emacs sources (.c, .h, .m, and .cc) we have 79
standard to 149 non-standard.  That's ~35% of enums looking like they've
been indented by private CC Mode styles, or by hand.

So my reservations from ten years ago about possible chaos were
misplaced; this chaos has already happened.

As an additional factor, the newish modes, c-ts-mode, c++-ts-mode, etc.,
indent in the standard fashion.  Also, these modes are hardly the cause
of the standard indentation in the Emacs sources, many of which date back
many years.

So it now seems clear that the decision not to fix the bug in 2014 was a
mistake.  I agree with you, it should be fixed now.

> Also, if there is intention to use automatic code formatting tools,
> which some have expressed as desirable for the toolchain projects (and I
> don't disagree - helps people who aren't using Emacs to get indent right
> easily ;-) ), having incorrect indentation by the editor will be
> burdensome, as it'd result in the editor and formatter fighting often.

> And, given that nobody (AFAIK) uses Emacs to mass-reindent code, I
> suspect the fallout of a fix will be gradual and silent.

> As an alternative to fixing this bug so that the token is recognized as
> a struct, we could have a new token for enum that does get indented
> correctly OOTB and that affected projects adjust to avoid trouble in
> their codebases.

That is one possibility, yes.  It seems clear that parsing enum
constructs as brace-lists is suboptimal, but I feel that parsing them as
structs, although easy, would be taking things just too far.  So I think
new symbols enum-open, etc., are the best way to go, even though this is
quite a lot of work (e.g. amending the CC Mode manual, the test suite,
....).

So, I will fix this bug.

[ .... ]

> No problem - thanks for responding :-)

> Have a lovely day.
> -- 
> Arsen Arsenović

-- 
Alan Mackenzie (Nuremberg, Germany).