bug#56848: CC Mode fontification bug

[Gregory Heytings]

> As an aside, one should be very careful with trusting the likes of
>
>   M-: (get-char-property 28 'fontified) RET
>
> because entering the minibuffer triggers a rather thorough redisplay 
> cycle, which could change the 'fontified' property one is trying to 
> obtain.  Instead, it is advisable to write a simple command that would 
> do the evaluation, then bind it to a single key, like F5, and invoke 
> through that key.  Even better, invoke the function from the debugger.
>
> (I'm not saying that the nil above is inaccurate, since the problematic 
> position is outside the window, I'm just saying one should be very 
> careful with this stuff.)

Indeed, I tried to make the recipe as simple as possible, but during my 
tests I did use such a function.

> The fact that the word 'window' is involved in both cases seems to ring 
> a bell: isn't there a feature in CC Mode's fontifications whereby it 
> does something with identifiers whose type it knows about, by going 
> forward and back into the buffer and "fixing" their fontifications?

Yes, that's what the 'c-fontify-new-found-type' modified by the patch 
does.  Currently, when a new type has been found, all occurrences of its 
identifier are "unfontified" with:

(widen)
(goto-char (point-min))
(while (re-search-forward ...) (put-text-property ... 'fontified nil))

When font locking has already put, say, a font-lock-comment-face, or a 
font-lock-function-name-face, or a font-lock-variable-name-face on an 
occurrence of that identifier, there is no reason to undo that.  It is 
only occurrences that have been marked as "fontified" but on which no face 
has been put that should be unfontified.