bug#57318: 29.0.50; c++-mode: Functions are shown as variables: partial template specialization

[Alan Mackenzie <acm@muc.de>]

Hello, Naofumi.

On Thu, Sep 01, 2022 at 01:01:56 +0900, Naofumi Yasufuku wrote:
> Hello Alan,

[ .... ]

> > When this dynamic binding is instead at nil (rather than t), the
> > fontification works properly, with functions fontified as functions.
> > The reason for this faulty binding was fixing a bug report where
> > scrolling a buffer containing lots of templates was very slow.  Binding
> > c-restricted-<>-arglists to t "solved" that slowness.


> Indeed.  I confirmed that avoiding (c-restricted-<>-arglists t) binding
> solves this misfontification problem at least, but it makes scrolling
> terribly slow...

Yes.  For the bug in 2019 for which I "fixed" this, the scrolling was
around a factor of 6 slower.

[ .... ]

> [..snip..]
> > Can I ask you, please, to apply and test my proposed patch, which I
> > enclose below.  Would you please test it on your real C++ source code,
> > and either confirm it really works, or say what's still faulty about it.
> > If there are any problems with applying the patch, feel free to send me
> > personal email.


> I've applied your patch.  It works well and solves misfontification
> problem.  At the same time, I've not seen any noticeable performance
> degradation by this patch so far.  Great.

Many thanks!

I've committed the patch to the standalone CC Mode repository and the
Emacs master branch at savannah.  I'm closing the bug with this post.

>   attachment: fix_c-restricted--arglists_verification.png

> I came across this problem when I tried to compare the current
> tree-sitter's fontification quality and performance with familiar
> cc-mode by using very-fast flat_hash_map code [1][2].  Now problematic
> fontification has gone.

In the long run, tree-sitter (or something like it) is going to be
superseding CC Mode.  Keeping up with the constantly evolving standards
in CC Mode has proven to be just too much work.  :-(

[ .... ]

> Best regards,
>   Naofumi

> [1] https://github.com/skarupke/flat_hash_map/blob/master/flat_hash_map.hpp
> [2] https://probablydance.com/2017/02/26/i-wrote-the-fastest-hashtable/

-- 
Alan Mackenzie (Nuremberg, Germany).