bug#24377: 25.1; CC-Mode (C++) uses font-lock-type-face for ordinary variable

[Alan Mackenzie]

Hello, Bastian.

On Tue, Sep 13, 2016 at 10:24:40PM +0200, Bastian Beischer wrote:
> Hello Alan,

> First of all, thanks for the patch - it's appreciated. My comments
> below:

> Alan Mackenzie <acm@muc.de> writes:

> > In article <mailman.1977.1473362155.22741.bug-gnu-emacs@gnu.org> you wrote:

> >> This piece of C++ code is wrongly fontified by CC-Mode:

> >> int b = 5;
> >> int a = (b*3);

> >> Reproduce as follows:

> >> 1) emacs -Q
> >> 2) Open file "test.C"
> >> 3) Paste snippet in buffer
> >> 4) Place cursor over "b" in second line
> >> 5) M-x describe-face -> font-lock-type-face

> >> This appears to be correlated with the presence of the opening
> >> parentheses and the '*' character, because:

> >> 1) int a = b*3;
> >> does not have this problem

> >> 2) "b" gets fontified incorrectly after entering the '*' character:
> >> int a = (b*

> > Thanks for this bug report, and thanks even more for taking the trouble
> > to reduce the test case to just two lines.

> >> In GNU Emacs 25.1.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.30)
> >>  of 2016-08-30 built on beischer-w520
> >> Repository revision: 17197d0ae9eac100b56078b2a48964b29710b76e
> >> Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
> >> Configured using:
> >>  'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
> >>  --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
> >>  --with-sound=alsa --with-xft --with-modules --with-x-toolkit=gtk2
> >>  --with-gconf --without-gsettings 'CFLAGS=-march=native -O2 -pipe
> >>  -fstack-protector-strong' CPPFLAGS=-D_FORTIFY_SOURCE=2
> >>  LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

> > [ .... ]

> > Yes, the CC Mode fontification code was confusing the "*" with an
> > indirection operator, such as you might get in "int (*b) (....);"

> > The solution seems to be to recognise the case where an arithmetic
> > operator (including "=") precedes the open parenthesis.  This is what the
> > following patch does.  Would you please try out this patch on real code,
> > and let me know whether the problem is completely fixed, and if not,
> > what's still going wrong.  Thanks!


> Yes this helps in the example above, but I'm not sure this is a fully
> correct solution. One can write something like this:

> void f(int arg)  {
>      printf("%d\n", arg)
> }

> f(a*5);

> Another example:

> int d(a*5)

> In both cases a is also wrongly fontified (and still is after applying
> the patch).

Sorry, but in the end I wasn't able to fix this problem.

There is now just too much ambiguity in C++'s syntax.  The "int d(a*5)"
is a sort of special case variant of "int d(a*b)".  This could either be
a declaration of d which is initialised to a*b, or the declaration of a
function d taking one parameter b whose type is a pointer to a.

C++ Mode, being an almost purely syntactic editor has no way to resolve
these ambiguities.  It seems not really worthwhile to handle the special
case of a literal integer following the "*".  So I have left that
construct being fontified as the function declaration, which is probably
the more common case.

So, I have committed the patch as it was when I last sent it to you for
review in September, and I am closing this bug.  Sorry, again.

> Thanks a lot again!


> -- 
> Bastian Beischer
> RWTH Aachen University of Technology

-- 
Alan Mackenzie (Nuremberg, Germany).