RE: Font-lock assumes C++ variables instantiated via ctor are fun ctions

[Marshall, Simon]

Hi, I noticed during my weekly cvs update that cyd applied my recent patch
for "Font-lock fontifies C/C++ case keyword as a constant", thanks.

The below earlier patch for another bug hasn't been applied, was it missed?

Thanks, Simon.

-----Original Message-----
From: Marshall, Simon 
Sent: 02 November 2006 10:48
To: 'address@hidden'; 'address@hidden'
Cc: 'Feng Li'
Subject: RE: Font-lock assumes C++ variables instantiated via ctor are
functions

Here is a patch that fixes the below problem for cvs emacs.

Feng Li sent me a patch that indicated to me where I could fix the problem
using the same solution used in previous versions of emacs.

2006-11-02  Simon Marshall  <address@hidden>

        * progmodes/cc-fonts.el (c-font-lock-declarators): Use
c-at-toplevel-p
        to recognise T t() as a function declaration, rather than a variable
        instantiation, iff at the top-level or inside a class declaration.
        From an idea from Feng Li <address@hidden>.

===================================================================
RCS file: /sources/emacs/emacs/lisp/progmodes/cc-fonts.el,v
retrieving revision 1.16
diff -r1.16 cc-fonts.el
900c900,904
<           id-face (if (eq (char-after next-pos) ?\()
---
>           id-face (if (and (eq (char-after next-pos) ?\()
>                            (let (c-last-identifier-range)
>                              (save-excursion
>                                (goto-char next-pos)
>                                (c-at-toplevel-p))))

Simon.

> -----Original Message-----
> From: Marshall, Simon
> Sent: 06 September 2006 10:28
> To: 'address@hidden'
> Cc: 'address@hidden'
> Subject: Font-lock assumes C++ variables instantiated via ctor are 
> functions
> 
> Consider this C++ code:
> 
> class Fubar { // Fubar as type - OK
>   Fubar();            // Fubar as function - OK
>   Fubar a;            // a as variable - OK
>   Fubar b();  // b as function - OK
>   Fubar c(A); // c as function - OK
> };
> 
> Fubar f;              // f as variable - OK
> Fubar g();            // y as function - OK
> Fubar h(f);           // z as function - probably OK really
> 
> int fubar()
> {
>   Fubar x;            // x as variable - OK
>   Fubar y();  // y as function - OK
>   Fubar z(X); // z as function - not OK
> }
> 
> In Emacs 21, assuming you had added "Fubar" to
> c++-font-lock-extra-types, y and z would be fontified as
> variables, on the basis that declaring functions locally (as for y) is 
> not common whereas z is almost certainly a variable and is very 
> common.  In other words, it usually does the right thing.  (Emacs 21 
> fontified y/z differently, IIRC by virtue of them being within a block 
> but not being part of a class declaration.)
> 
> In the current Emacs 22 from CVS, you don't have to add to
> c++-font-lock-extra-types, which is great.  However, y and z
> are fontified as functions.  In other words, it usually does the wrong 
> thing.
> 
> Obviously, it's very difficult to get this right without writing a C++ 
> parser.  It really isn't clear what is the best thing to do for h, 
> since it really could be either a function or a variable declaration 
> (you would have to pick apart the parameters and consult the gods).  
> But z is almost certainly going to be a variable declaration and this 
> style of variable instantiation is obviously very common.