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

[Marshall, Simon]

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.