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

[Ivan Andrus <darthandrus@gmail.com>]

On Aug 31, 2013, at 2:56 PM, Alan Mackenzie <acm@muc.de> wrote:

> 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:

I have been using your diff below for a few days, and I haven't noticed any negative side effects.

There are still two things that don't fontify correctly:


#define DELETE_MEMBER = delete
class Bob
{
    Bob &operator=(Bob const &) = delete; // fontified (with diff applied)
    Bob &operator=(Bob const &) DELETE_MEMBER; // not fontified with or without diff

    Bob( string );    // string is a `font-lock-type-face'
    explicit Bob( string ); // string is `font-lock-variable-name-face'
};


The first bad fontification seems to be caused because it doesn't understand the macro which probably can't be helped.  The second though is a bit more concerning, though it seems to be unrelated to the current bug.  I will probably open another bug for it unless you'd prefer I didn't


> 
> 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.  ;-)

Don't worry, it doesn't last long.  :-)

>> 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.

Based on how quickly you responded, I wish I had reported it long ago.

Thanks again,
Ivan