bug#50640: 28.0.50; incorrect highlighting in C++ mode

bug#50640: 28.0.50; incorrect highlighting in C++ mode

[Vincent Lefevre]

Consider a test.cc file containing:

  if (xMin - xt < t3Font->glyphX ||
      yMin - yt < t3Font->glyphY ||
      xMax - xt > t3Font->glyphX + t3Font->glyphW ||
      yMax - yt > t3Font->glyphY + t3Font->glyphH) {
  }

(this comes from the xpdf source) and open it with "emacs -Q".

The first two "xt" and "yt" are highlighted in green instead of
remaining in black. If I remove the last condition as follows
and reopen the file:

  if (xMin - xt < t3Font->glyphX ||
      yMin - yt < t3Font->glyphY ||
      xMax - xt > t3Font->glyphX + t3Font->glyphW) {
  }

then only the "yt" is highlighted incorrectly.


In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0)
 of 2021-09-17 built on zira
Repository revision: 8220df9355e105459e91623dd63f7a08a08cfe09
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux bookworm/sid

Configured using:
 'configure --prefix=/home/vinc17/opt/emacs-master'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LC_COLLATE: POSIX
  value of $LC_CTYPE: C.UTF-8
  value of $LC_TIME: en_DK.utf8
  value of $LANG: POSIX
  locale-coding-system: utf-8-unix

Major mode: C++//l

Minor modes in effect:
  display-time-mode: t
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr warnings emacsbug message rmc puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util rmail rmail-loaddefs auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache json map text-property-search
time-date subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
cc-mode cc-fonts cc-guess cc-menus cc-cmds time cus-load paren cc-styles
cc-align cc-engine cc-vars cc-defs edmacro kmacro cl-loaddefs cl-lib
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 80328 6010)
 (symbols 48 9599 1)
 (strings 32 26386 987)
 (string-bytes 1 979203)
 (vectors 16 13517)
 (vector-slots 8 174949 9740)
 (floats 8 28 46)
 (intervals 56 237 0)
 (buffers 992 12))

bug#50640: 28.0.50; incorrect highlighting in C++ mode

[Stefan Kangas]

Vincent Lefevre <vincent@vinc17.net> writes:

> Consider a test.cc file containing:
>
>   if (xMin - xt < t3Font->glyphX ||
>       yMin - yt < t3Font->glyphY ||
>       xMax - xt > t3Font->glyphX + t3Font->glyphW ||
>       yMax - yt > t3Font->glyphY + t3Font->glyphH) {
>   }
>
> (this comes from the xpdf source) and open it with "emacs -Q".
>
> The first two "xt" and "yt" are highlighted in green instead of
> remaining in black. If I remove the last condition as follows
> and reopen the file:
>
>   if (xMin - xt < t3Font->glyphX ||
>       yMin - yt < t3Font->glyphY ||
>       xMax - xt > t3Font->glyphX + t3Font->glyphW) {
>   }
>
> then only the "yt" is highlighted incorrectly.

Alan, could you take a look at this bug report?

(I don't know if you're subscribed to the bug list, my apologies if you
have already seen it.)

bug#50640: 28.0.50; incorrect highlighting in C++ mode

[Alan Mackenzie]

Hello, Vincent and Stefan.

On Sat, Sep 25, 2021 at 11:17:07 -0700, Stefan Kangas wrote:
> Vincent Lefevre <vincent@vinc17.net> writes:

> > Consider a test.cc file containing:

> >   if (xMin - xt < t3Font->glyphX ||
> >       yMin - yt < t3Font->glyphY ||
> >       xMax - xt > t3Font->glyphX + t3Font->glyphW ||
> >       yMax - yt > t3Font->glyphY + t3Font->glyphH) {
> >   }

> > (this comes from the xpdf source) and open it with "emacs -Q".

> > The first two "xt" and "yt" are highlighted in green instead of
> > remaining in black.

Yes.  C++ Mode is recognising the < .. < .. > .. > as two nested
templates.  The green is font-lock-type-face.  :-(

> > If I remove the last condition as follows and reopen the file:

> >   if (xMin - xt < t3Font->glyphX ||
> >       yMin - yt < t3Font->glyphY ||
> >       xMax - xt > t3Font->glyphX + t3Font->glyphW) {
> >   }

> > then only the "yt" is highlighted incorrectly.

Yes, then only yt opens a "template", there being no closing > to balance
the xt <.

There's really not much which can be done about this in CC Mode, sorry.
CC Mode's analysis of ambiguous C++ constructs is not very deep, so it
sometimes gets it wrong, as here.

I would be in favour of closing this bug as "won't fix" (actually, can't
fix).

There's an intention in the medium future to introduce rigorous analyses
of source code into Emacs with a language server protocol program called
"Tree Sitter".  That should solve problems like this one.

In the meantime, a workaround would be to change the order of the terms
in that expression so that the <s come after the >s rather than before
them, if you have control of the source code.

> Alan, could you take a look at this bug report?

> (I don't know if you're subscribed to the bug list, my apologies if you
> have already seen it.)

I'm not actually subscribed to the bug list.  I'd have trouble coping
with the volume of posts there.  I try to skim over the archive on the
web every week or so, to try not to miss anything.  So thanks, Stefan,
for the heads up!

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#50640: 28.0.50; incorrect highlighting in C++ mode

[Vincent Lefevre]

On 2021-09-25 21:17:06 +0000, Alan Mackenzie wrote:
> Hello, Vincent and Stefan.
> 
> On Sat, Sep 25, 2021 at 11:17:07 -0700, Stefan Kangas wrote:
> > Vincent Lefevre <vincent@vinc17.net> writes:
> 
> > > Consider a test.cc file containing:
> 
> > >   if (xMin - xt < t3Font->glyphX ||
> > >       yMin - yt < t3Font->glyphY ||
> > >       xMax - xt > t3Font->glyphX + t3Font->glyphW ||
> > >       yMax - yt > t3Font->glyphY + t3Font->glyphH) {
> > >   }
> 
> > > (this comes from the xpdf source) and open it with "emacs -Q".
> 
> > > The first two "xt" and "yt" are highlighted in green instead of
> > > remaining in black.
> 
> Yes.  C++ Mode is recognising the < .. < .. > .. > as two nested
> templates.  The green is font-lock-type-face.  :-(
> 
> > > If I remove the last condition as follows and reopen the file:
> 
> > >   if (xMin - xt < t3Font->glyphX ||
> > >       yMin - yt < t3Font->glyphY ||
> > >       xMax - xt > t3Font->glyphX + t3Font->glyphW) {
> > >   }
> 
> > > then only the "yt" is highlighted incorrectly.
> 
> Yes, then only yt opens a "template", there being no closing > to balance
> the xt <.
> 
> There's really not much which can be done about this in CC Mode, sorry.
> CC Mode's analysis of ambiguous C++ constructs is not very deep, so it
> sometimes gets it wrong, as here.

Note that when < .. < .. > .. > comparisons occur, there is
probably || or && between them. Are C++ nested templates common
with || or && inside them? If not, || and && should be forbidden
in nested template matching.

Alternatively, whitespace characters could also give a hint:
AFAIK, for templates, this is usually no whitespace after '<'
and no whitespace before '>'.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#50640: 28.0.50; incorrect highlighting in C++ mode

[Lars Ingebrigtsen]

Alan Mackenzie <acm@muc.de> writes:

> There's really not much which can be done about this in CC Mode, sorry.
> CC Mode's analysis of ambiguous C++ constructs is not very deep, so it
> sometimes gets it wrong, as here.
>
> I would be in favour of closing this bug as "won't fix" (actually, can't
> fix).

OK; closing this as a "wontfix", then.

bug#50640: 28.0.50; incorrect highlighting in C++ mode

[Vincent Lefevre]

On 2022-08-26 13:42:24 +0200, Lars Ingebrigtsen wrote:
> Alan Mackenzie <acm@muc.de> writes:
> 
> > There's really not much which can be done about this in CC Mode, sorry.
> > CC Mode's analysis of ambiguous C++ constructs is not very deep, so it
> > sometimes gets it wrong, as here.
> >
> > I would be in favour of closing this bug as "won't fix" (actually, can't
> > fix).
> 
> OK; closing this as a "wontfix", then.

Isn't it really possible to have an option to forbid && and ||
in <...> constructs?

I think that this would be useful in practice, because when && or ||
is involved, < and > around them probably mean comparisons.

Note that the issue is more general than nested < .. < .. > .. >.
Bad highlighting also occurs just with "a < b || c > d".

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)