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

[Ivan Andrus]

On Sep 18, 2013, at 3:19 PM, Alan Mackenzie <acm@muc.de> wrote:

> Hi, Ivan.
> 
> On Tue, Sep 10, 2013 at 02:04:31PM -0600, Ivan Andrus wrote:
> 
>> On Aug 31, 2013, at 2:56 PM, Alan Mackenzie <acm@muc.de> wrote:
> 
>>> 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.
> 
> Thanks.  I've committed the patch to the bazaar repository and marked the
> bug as closed.
> 
>> 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.
> 
> I think so.  Though I don't understand what the "= delete;" bit means
> (I'm not a C++ hacker).

It means don't automatically generate the function (in this case the 
assignment operator).  Normally the compiler will automatically create
certain functions like destructors.

>> 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
> 
> I'd rather you did open a separate bug, please.  As a matter of interest,
> in "Bob( string );" (without the "explicit"), I don't get either
> identifier fontified. 

It's now bug 15415.

>> Thanks again,
>> Ivan
> 
> -- 
> Alan Mackenzie (Nuremberg, Germany).