emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Font-lock assumes C++ variables instantiated via ctor are functio ns


From: Marshall, Simon
Subject: Font-lock assumes C++ variables instantiated via ctor are functio ns
Date: Wed, 6 Sep 2006 10:28:24 +0100

I'm fairly sure this never made it to the lists, so here it is again...
I'm not on either mailing list, so plz include me directly if you have
questions.

-----Original Message-----
From: Marshall, Simon 
Sent: 16 August 2006 18:30
To: 'address@hidden'
Cc: 'Emacs Pretest Bug (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.

I'm off on holiday, so let the flame fest begin!  Simon.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]