bug#15211: 24.3.50; Incorrect fontification in c++-mode

[Alan Mackenzie]

Hi, Ivan.

> In C and C++ it is legal to place the const to the right of the type as below:

> Json parseJson( string const &json );

> However, this results in "string" not being fontified as a type
> (i.e. with `font-lock-type-face').  It seems to work some times, but the
> minimal example above does not when starting from `emacs -q`.

Yes.  There is special code in `c-forward-type' that causes different
return codes for "string const" and "string".  These two return codes are
specifically differentiated (at the end of `c-forward-decl-or-cast-1')
when deciding whether or not to fontify the identifier.

I've not been able to understand why this code does this - the code has
been in place for well over a decade, and I've been looking at old change
logs.  The following patch disables the distinction and always fontifies
the identifier.  Please try it out and let me know if any undesirable
side effects occur, or if it doesn't quite fix the problem in real code:



diff -r 45df171f9859 cc-engine.el
--- a/cc-engine.el      Sat Aug 31 11:09:30 2013 +0000
+++ b/cc-engine.el      Sat Aug 31 20:32:22 2013 +0000
@@ -7440,7 +7440,8 @@
        ;; interactive refontification.
        (c-put-c-type-property (point) 'c-decl-arg-start))
 
-      (when (and c-record-type-identifiers at-type (not (eq at-type t)))
+      (when (and c-record-type-identifiers at-type ;; (not (eq at-type t))
+                )
        (let ((c-promote-possible-types t))
          (save-excursion
            (goto-char type-start)


After applying the patch to .../lisp/progmodes/cc-engine.el, just
recompile cc-engine.el with M-x byte-compile-file <CR> cc-engine.el, then
reload cc-engine.elc with M-x load-file <CR> cc-engine.elc.

> Although this is fairly uncommon, there are valid reasons for doing this
> (see http://www.dansaks.com/articles/1999-02%20const%20T%20vs%20T%20const.pdf
> for example), and at work it's ubiquitous.  The lack of fontification is
> annoying since it gives me vi envy. :-)

We can't have that.  ;-)

> Thanks for the overall excellent cc-mode(s)!

And thank you for taking the trouble to report this bug, and even more
for such a high quality bug report.

-Ivan

-- 
Alan Mackenzie (Nuremberg, Germany).