Suboptimal bug fix in CC Mode.

Suboptimal bug fix in CC Mode.

[Alan Mackenzie]

Hello, Eli.

Unfortunately, a sub-optimal bug fix with unintended consequences has
found its way into Emacs-26 (and master).  The bug fix was a new CC Mode
feature, C99 compound literals.  This involves allowing brace blocks in
more contexts than previously, where a brace block essentially only
followed "=".

The "fix" adopted was to examine the inside of "{ ... }" to determine
whether it's a brace block or a statement/defun block.  Essentially, a
"," means brace block and ";" means statement/defun block.

This strategem falls down in the following use case.  Type in

    int main () {
        int a
    }

, where the closing "}" is optional.  Now type a "," after the
identifier "a".  CC Mode now interprets the line as a brace-block-entry,
and indents it suboptimally.  This indentation can need fixing by hand,
after a ";" has caused the block to become a defun block.

This new feature, compound literals, was requested by Nikolai Weibull in
emacs-devel on 2017-08-15, and the "fix" committed by me on 2017-11-10.
I became aware of the defects of this "fix" two days ago, when bug
#29959 was reported by Konstantin Kharlamov.

I don't think we should leave this bug in Emacs-26.

Clearly, analysing the innards of "{ ... }" is not a reliable way to
distinguish brace blocks from statement/defun blocks.  Instead, more
elaborate analysis of its context needs to be carried out.  This fix
will be quite involved, and will be considerably more extensive than a
"one-line fix".

Alternatively, the C99 compound literals feature could be removed from
Emacs-26 and postponed till Emacs-27.

Sorry.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Suboptimal bug fix in CC Mode.

[Eli Zaretskii]

> Date: Mon, 15 Jan 2018 22:00:12 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> I don't think we should leave this bug in Emacs-26.

Agreed.

> Clearly, analysing the innards of "{ ... }" is not a reliable way to
> distinguish brace blocks from statement/defun blocks.  Instead, more
> elaborate analysis of its context needs to be carried out.  This fix
> will be quite involved, and will be considerably more extensive than a
> "one-line fix".
> 
> Alternatively, the C99 compound literals feature could be removed from
> Emacs-26 and postponed till Emacs-27.

I suggest that you revert the fix from the release branch, but leave
it on master, and try to fix it there.  Please mark the revert as "not
to be merged to master".

Thanks.

> Sorry.

No sweat.

Re: Suboptimal bug fix in CC Mode.

[Alan Mackenzie]

Hello, Eli.

On Tue, Jan 16, 2018 at 19:53:56 +0200, Eli Zaretskii wrote:
> > Date: Mon, 15 Jan 2018 22:00:12 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > I don't think we should leave this bug in Emacs-26.

> Agreed.

> > Clearly, analysing the innards of "{ ... }" is not a reliable way to
> > distinguish brace blocks from statement/defun blocks.  Instead, more
> > elaborate analysis of its context needs to be carried out.  This fix
> > will be quite involved, and will be considerably more extensive than a
> > "one-line fix".

> > Alternatively, the C99 compound literals feature could be removed from
> > Emacs-26 and postponed till Emacs-27.

> I suggest that you revert the fix from the release branch, but leave
> it on master, and try to fix it there.  Please mark the revert as "not
> to be merged to master".

I've now reverted that change on the emacs-26 branch, complete with a
"don't merge" instruction.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Suboptimal bug fix in CC Mode.

[Alan Mackenzie]

Hello, Eli.

On Tue, Jan 16, 2018 at 19:53:56 +0200, Eli Zaretskii wrote:
> > Date: Mon, 15 Jan 2018 22:00:12 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

[ .... ]

> > Clearly, analysing the innards of "{ ... }" is not a reliable way to
> > distinguish brace blocks from statement/defun blocks.  Instead, more
> > elaborate analysis of its context needs to be carried out.  This fix
> > will be quite involved, and will be considerably more extensive than a
> > "one-line fix".

[ .... ]

> I suggest that you revert the fix from the release branch, but leave
> it on master, and try to fix it there.  Please mark the revert as "not
> to be merged to master".

I've just committed an attempted fix to master.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Suboptimal bug fix in CC Mode.

[John Wiegley]

>>>>> "AM" == Alan Mackenzie <acm@muc.de> writes:

AM> I've now reverted that change on the emacs-26 branch, complete with a
AM> "don't merge" instruction.

Thanks, Alan. I agree with Eli that it's better not to attempt the new fix in
the release branch.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2