bug#61403: 30.0.50; C tree-sitter bug?

bug#61403: 30.0.50; C tree-sitter bug?

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Go to sfnt.c in the feature/android branch, and turn on c-ts-mode.

Then, go to line 10754, around which should be the function definition:

/* Load the simple glyph GLYPH into the specified INTERPRETER, scaling
   it up by INTERPRETER's scale, and run its glyph program if
   present.  Use the unscaled metrics specified in METRICS.

   Upon success, return NULL and the resulting points and contours in
   *VALUE.  Else, value is the reason interpretation failed.  */

TEST_STATIC const char *
sfnt_interpret_simple_glyph (struct sfnt_glyph *glyph,
			     struct sfnt_interpreter *interpreter,
			     struct sfnt_glyph_metrics *metrics,
			     struct sfnt_instructed_outline **value)
{
  size_t zone_size, temp, outline_size, i;
  struct sfnt_interpreter_zone *zone;
  struct sfnt_interpreter_zone *volatile preserved_zone;
  sfnt_f26dot6 phantom_point_1_x;

`TEST_STATIC' is fontified as a type.  Perhaps tree-sitter needs
something along the lines of `c-noise-macros'?

Likewise for _Noreturn:

_Noreturn static void
sfnt_interpret_trap (struct sfnt_interpreter *interpreter,
		     const char *reason)
{

_Noreturn is a keyword in 2011 Standard C.  I think the tree-sitter
parser definition files should be updated to understand it.


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu) of 2023-02-10 built
 on RepoWS1
Repository revision: 680bc20553ebf01375ab7957b6f0be066335fd6e
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101099
System Description: Fedora Linux 37 (Workstation Edition)

Configured using:
 'configure --with-x --with-x-toolkit=no --without-cairo
 --with-dumping=unexec --cache-file=/tmp/ccache'

Configured features:
ACL DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LCMS2
LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY OLDXMENU PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TREE_SITTER UNEXEC WEBP X11 XDBE XFT
XIM XINPUT2 XPM ZLIB

Important settings:
  value of $LANG: en_GB.utf8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: C

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

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny rfc822
mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util
text-property-search time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils mule-util display-line-numbers
c-ts-mode cl-extra help-mode warnings icons c-ts-common treesit cl-seq
vc bug-reference byte-opt gv bytecomp byte-compile cc-mode cc-fonts
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
misearch multi-isearch vc-git diff-mode easy-mmode vc-dispatcher
dired-aux cl-loaddefs cl-lib dired dired-loaddefs shell subr-x pcomplete
comint ansi-osc ansi-color ring rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode 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 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 nadvice seq simple cl-generic
indonesian philippine 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 emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting xinput2 x
multi-tty make-network-process emacs)

Memory information:
((conses 16 222669 14119)
 (symbols 48 25643 0)
 (strings 32 45435 2367)
 (string-bytes 1 1362327)
 (vectors 16 26563)
 (vector-slots 8 868096 36136)
 (floats 8 84 104)
 (intervals 56 21736 0)
 (buffers 984 23))

bug#61403: 30.0.50; C tree-sitter bug?

[Yuan Fu]

Po Lu <luangruo@yahoo.com> writes:

> Go to sfnt.c in the feature/android branch, and turn on c-ts-mode.
>
> Then, go to line 10754, around which should be the function definition:
>
> /* Load the simple glyph GLYPH into the specified INTERPRETER, scaling
>    it up by INTERPRETER's scale, and run its glyph program if
>    present.  Use the unscaled metrics specified in METRICS.
>
>    Upon success, return NULL and the resulting points and contours in
>    *VALUE.  Else, value is the reason interpretation failed.  */
>
> TEST_STATIC const char *
> sfnt_interpret_simple_glyph (struct sfnt_glyph *glyph,
> 			     struct sfnt_interpreter *interpreter,
> 			     struct sfnt_glyph_metrics *metrics,
> 			     struct sfnt_instructed_outline **value)
> {
>   size_t zone_size, temp, outline_size, i;
>   struct sfnt_interpreter_zone *zone;
>   struct sfnt_interpreter_zone *volatile preserved_zone;
>   sfnt_f26dot6 phantom_point_1_x;
>
> `TEST_STATIC' is fontified as a type.  Perhaps tree-sitter needs
> something along the lines of `c-noise-macros'?

Would it be reasonable to assume that all caps "type" are almost always
macros? If it is, we can optionally defontify these kind of "types".

>
> Likewise for _Noreturn:
>
> _Noreturn static void
> sfnt_interpret_trap (struct sfnt_interpreter *interpreter,
> 		     const char *reason)
> {
>
> _Noreturn is a keyword in 2011 Standard C.  I think the tree-sitter
> parser definition files should be updated to understand it.

Makes sense. I can file an issue on tree-sitter-c’s repo.

Yuan

bug#61403: 30.0.50; C tree-sitter bug?

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Yuan Fu <casouri@gmail.com> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Go to sfnt.c in the feature/android branch, and turn on c-ts-mode.
>>
>> Then, go to line 10754, around which should be the function definition:
>>
>> /* Load the simple glyph GLYPH into the specified INTERPRETER, scaling
>>    it up by INTERPRETER's scale, and run its glyph program if
>>    present.  Use the unscaled metrics specified in METRICS.
>>
>>    Upon success, return NULL and the resulting points and contours in
>>    *VALUE.  Else, value is the reason interpretation failed.  */
>>
>> TEST_STATIC const char *
>> sfnt_interpret_simple_glyph (struct sfnt_glyph *glyph,
>> 			     struct sfnt_interpreter *interpreter,
>> 			     struct sfnt_glyph_metrics *metrics,
>> 			     struct sfnt_instructed_outline **value)
>> {
>>   size_t zone_size, temp, outline_size, i;
>>   struct sfnt_interpreter_zone *zone;
>>   struct sfnt_interpreter_zone *volatile preserved_zone;
>>   sfnt_f26dot6 phantom_point_1_x;
>>
>> `TEST_STATIC' is fontified as a type.  Perhaps tree-sitter needs
>> something along the lines of `c-noise-macros'?
>
> Would it be reasonable to assume that all caps "type" are almost always
> macros? If it is, we can optionally defontify these kind of "types".

Not really, because an extremely common type is:

    PTR_T *ptr;

where ``PTR_T'' is used to represent pointers on systems that may lack
properly working pointers to void.

The standard library FILE * is also one such type with a capitalized
name.

>>
>> Likewise for _Noreturn:
>>
>> _Noreturn static void
>> sfnt_interpret_trap (struct sfnt_interpreter *interpreter,
>> 		     const char *reason)
>> {
>>
>> _Noreturn is a keyword in 2011 Standard C.  I think the tree-sitter
>> parser definition files should be updated to understand it.
>
> Makes sense. I can file an issue on tree-sitter-c’s repo.

Please do so, and thanks.

bug#61403: 30.0.50; C tree-sitter bug?

[Eli Zaretskii]

> Cc: 61403@debbugs.gnu.org
> Date: Sun, 12 Feb 2023 16:36:10 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Yuan Fu <casouri@gmail.com> writes:
> 
> > Po Lu <luangruo@yahoo.com> writes:
> >
> >> Go to sfnt.c in the feature/android branch, and turn on c-ts-mode.
> >>
> >> Then, go to line 10754, around which should be the function definition:
> >>
> >> /* Load the simple glyph GLYPH into the specified INTERPRETER, scaling
> >>    it up by INTERPRETER's scale, and run its glyph program if
> >>    present.  Use the unscaled metrics specified in METRICS.
> >>
> >>    Upon success, return NULL and the resulting points and contours in
> >>    *VALUE.  Else, value is the reason interpretation failed.  */
> >>
> >> TEST_STATIC const char *
> >> sfnt_interpret_simple_glyph (struct sfnt_glyph *glyph,
> >> 			     struct sfnt_interpreter *interpreter,
> >> 			     struct sfnt_glyph_metrics *metrics,
> >> 			     struct sfnt_instructed_outline **value)
> >> {
> >>   size_t zone_size, temp, outline_size, i;
> >>   struct sfnt_interpreter_zone *zone;
> >>   struct sfnt_interpreter_zone *volatile preserved_zone;
> >>   sfnt_f26dot6 phantom_point_1_x;
> >>
> >> `TEST_STATIC' is fontified as a type.  Perhaps tree-sitter needs
> >> something along the lines of `c-noise-macros'?
> >
> > Would it be reasonable to assume that all caps "type" are almost always
> > macros? If it is, we can optionally defontify these kind of "types".
> 
> Not really, because an extremely common type is:
> 
>     PTR_T *ptr;
> 
> where ``PTR_T'' is used to represent pointers on systems that may lack
> properly working pointers to void.
> 
> The standard library FILE * is also one such type with a capitalized
> name.

I admit I don't understand the problem that is the subject of this
bug.  Why is it wrong to fontify TEST_STATIC as a type?  CC mode also
fontifies it as a type, btw.

The only problem I see in what c-ts-mode does is that it does NOT
fontify 'char', whereas CC mode does.  So if anything needs to be done
here, we need to look into why 'char' is not fontified by c-ts-mode.

Or what am I missing?

bug#61403: 30.0.50; C tree-sitter bug?

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 61403@debbugs.gnu.org
>> Date: Sun, 12 Feb 2023 16:36:10 +0800
>> From:  Po Lu via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> Yuan Fu <casouri@gmail.com> writes:
>> 
>> > Po Lu <luangruo@yahoo.com> writes:
>> >
>> >> Go to sfnt.c in the feature/android branch, and turn on c-ts-mode.
>> >>
>> >> Then, go to line 10754, around which should be the function definition:
>> >>
>> >> /* Load the simple glyph GLYPH into the specified INTERPRETER, scaling
>> >>    it up by INTERPRETER's scale, and run its glyph program if
>> >>    present.  Use the unscaled metrics specified in METRICS.
>> >>
>> >>    Upon success, return NULL and the resulting points and contours in
>> >>    *VALUE.  Else, value is the reason interpretation failed.  */
>> >>
>> >> TEST_STATIC const char *
>> >> sfnt_interpret_simple_glyph (struct sfnt_glyph *glyph,
>> >> 			     struct sfnt_interpreter *interpreter,
>> >> 			     struct sfnt_glyph_metrics *metrics,
>> >> 			     struct sfnt_instructed_outline **value)
>> >> {
>> >>   size_t zone_size, temp, outline_size, i;
>> >>   struct sfnt_interpreter_zone *zone;
>> >>   struct sfnt_interpreter_zone *volatile preserved_zone;
>> >>   sfnt_f26dot6 phantom_point_1_x;
>> >>
>> >> `TEST_STATIC' is fontified as a type.  Perhaps tree-sitter needs
>> >> something along the lines of `c-noise-macros'?
>> >
>> > Would it be reasonable to assume that all caps "type" are almost always
>> > macros? If it is, we can optionally defontify these kind of "types".
>> 
>> Not really, because an extremely common type is:
>> 
>>     PTR_T *ptr;
>> 
>> where ``PTR_T'' is used to represent pointers on systems that may lack
>> properly working pointers to void.
>> 
>> The standard library FILE * is also one such type with a capitalized
>> name.
>
> I admit I don't understand the problem that is the subject of this
> bug.  Why is it wrong to fontify TEST_STATIC as a type?  CC mode also
> fontifies it as a type, btw.

Yes, but CC Mode provides `c-noise-macro-names'.  I said something
similar should exist in c-ts-mode at the beginning of this thread.

> The only problem I see in what c-ts-mode does is that it does NOT
> fontify 'char', whereas CC mode does.  So if anything needs to be done
> here, we need to look into why 'char' is not fontified by c-ts-mode.

Apparently tree-sitter thinks only TEST_STATIC is the type, and
everything else is a syntactic error.

bug#61403: 30.0.50; C tree-sitter bug?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: casouri@gmail.com,  61403@debbugs.gnu.org
> Date: Sun, 12 Feb 2023 18:30:41 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I admit I don't understand the problem that is the subject of this
> > bug.  Why is it wrong to fontify TEST_STATIC as a type?  CC mode also
> > fontifies it as a type, btw.
> 
> Yes, but CC Mode provides `c-noise-macro-names'.  I said something
> similar should exist in c-ts-mode at the beginning of this thread.

Maybe so, but not for this case: I see absolutely no reason to
"de-fontify" TEST_STATIC here, as it is part of the type.

> > The only problem I see in what c-ts-mode does is that it does NOT
> > fontify 'char', whereas CC mode does.  So if anything needs to be done
> > here, we need to look into why 'char' is not fontified by c-ts-mode.
> 
> Apparently tree-sitter thinks only TEST_STATIC is the type, and
> everything else is a syntactic error.

Whatever the reasons, we need to try to fix this part.

bug#61403: 30.0.50; C tree-sitter bug?

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: casouri@gmail.com,  61403@debbugs.gnu.org
>> Date: Sun, 12 Feb 2023 18:30:41 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > I admit I don't understand the problem that is the subject of this
>> > bug.  Why is it wrong to fontify TEST_STATIC as a type?  CC mode also
>> > fontifies it as a type, btw.
>> 
>> Yes, but CC Mode provides `c-noise-macro-names'.  I said something
>> similar should exist in c-ts-mode at the beginning of this thread.
>
> Maybe so, but not for this case: I see absolutely no reason to
> "de-fontify" TEST_STATIC here, as it is part of the type.

It actually ``static'' on TEST builds or nothing at all, not part of the
type.  It ought not to be fontified, just as we don't fontify _Noreturn
or __attribute__ as types.

>> > The only problem I see in what c-ts-mode does is that it does NOT
>> > fontify 'char', whereas CC mode does.  So if anything needs to be done
>> > here, we need to look into why 'char' is not fontified by c-ts-mode.
>> 
>> Apparently tree-sitter thinks only TEST_STATIC is the type, and
>> everything else is a syntactic error.
>
> Whatever the reasons, we need to try to fix this part.

Yes, please.  Also the bit about _Noreturn.

bug#61403: 30.0.50; C tree-sitter bug?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: casouri@gmail.com,  61403@debbugs.gnu.org
> Date: Sun, 12 Feb 2023 20:36:22 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Maybe so, but not for this case: I see absolutely no reason to
> > "de-fontify" TEST_STATIC here, as it is part of the type.
> 
> It actually ``static'' on TEST builds or nothing at all, not part of the
> type.

The above actually means that it _is_ part of the type.

> It ought not to be fontified, just as we don't fontify _Noreturn
> or __attribute__ as types.

In 'static char', "static" is part of the type.

bug#61403: 30.0.50; C tree-sitter bug?

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> It actually ``static'' on TEST builds or nothing at all, not part of the
>> type.
>
> The above actually means that it _is_ part of the type.
>
>> It ought not to be fontified, just as we don't fontify _Noreturn
>> or __attribute__ as types.
>
> In 'static char', "static" is part of the type.

In a declaration like so:

static char *
foo (void)
{

}

ANSI C states that ``static'' is a storage class specifier, not a type
specifier or qualifier, definitely not part of the type, which is ``char
*''.

CC Mode normally fontifies this accordingly, in font-lock-keyword-face.

bug#61403: 30.0.50; C tree-sitter bug?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: casouri@gmail.com,  61403@debbugs.gnu.org
> Date: Sun, 12 Feb 2023 22:12:12 +0800
> 
> static char *
> foo (void)
> {
> 
> }
> 
> ANSI C states that ``static'' is a storage class specifier, not a type
> specifier or qualifier, definitely not part of the type, which is ``char
> *''.
> 
> CC Mode normally fontifies this accordingly, in font-lock-keyword-face.

Only for types qualifiers it knows about.  There are a lot of examples
in w32*.c files, here's one (fron line 610 of w32.c):

  static BOOL WINAPI
  open_process_token (HANDLE ProcessHandle,
		      DWORD DesiredAccess,
		      PHANDLE TokenHandle)

I think we are splitting hair here.  In the code snippet you posted in
the OP, the non-fontification of 'char' is the only real issue.