* bug#61403: 30.0.50; C tree-sitter bug? [not found] <87h6vt364d.fsf.ref@yahoo.com> @ 2023-02-10 15:14 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-02-12 8:27 ` Yuan Fu 0 siblings, 1 reply; 10+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-02-10 15:14 UTC (permalink / raw) To: 61403 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)) ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#61403: 30.0.50; C tree-sitter bug? 2023-02-10 15:14 ` bug#61403: 30.0.50; C tree-sitter bug? Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-02-12 8:27 ` Yuan Fu 2023-02-12 8:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 10+ messages in thread From: Yuan Fu @ 2023-02-12 8:27 UTC (permalink / raw) To: Po Lu; +Cc: 61403 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#61403: 30.0.50; C tree-sitter bug? 2023-02-12 8:27 ` Yuan Fu @ 2023-02-12 8:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-02-12 8:56 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-02-12 8:36 UTC (permalink / raw) To: Yuan Fu; +Cc: 61403 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#61403: 30.0.50; C tree-sitter bug? 2023-02-12 8:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-02-12 8:56 ` Eli Zaretskii 2023-02-12 10:30 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2023-02-12 8:56 UTC (permalink / raw) To: Po Lu; +Cc: 61403, casouri > 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? ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#61403: 30.0.50; C tree-sitter bug? 2023-02-12 8:56 ` Eli Zaretskii @ 2023-02-12 10:30 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-02-12 12:31 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-02-12 10:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 61403, casouri 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#61403: 30.0.50; C tree-sitter bug? 2023-02-12 10:30 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-02-12 12:31 ` Eli Zaretskii 2023-02-12 12:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2023-02-12 12:31 UTC (permalink / raw) To: Po Lu; +Cc: 61403, casouri > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#61403: 30.0.50; C tree-sitter bug? 2023-02-12 12:31 ` Eli Zaretskii @ 2023-02-12 12:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-02-12 13:04 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-02-12 12:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 61403, casouri 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#61403: 30.0.50; C tree-sitter bug? 2023-02-12 12:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-02-12 13:04 ` Eli Zaretskii 2023-02-12 14:12 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2023-02-12 13:04 UTC (permalink / raw) To: Po Lu; +Cc: 61403, casouri > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#61403: 30.0.50; C tree-sitter bug? 2023-02-12 13:04 ` Eli Zaretskii @ 2023-02-12 14:12 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-02-12 14:36 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-02-12 14:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 61403, casouri 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#61403: 30.0.50; C tree-sitter bug? 2023-02-12 14:12 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-02-12 14:36 ` Eli Zaretskii 0 siblings, 0 replies; 10+ messages in thread From: Eli Zaretskii @ 2023-02-12 14:36 UTC (permalink / raw) To: Po Lu; +Cc: 61403, casouri > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-02-12 14:36 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <87h6vt364d.fsf.ref@yahoo.com> 2023-02-10 15:14 ` bug#61403: 30.0.50; C tree-sitter bug? Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-02-12 8:27 ` Yuan Fu 2023-02-12 8:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-02-12 8:56 ` Eli Zaretskii 2023-02-12 10:30 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-02-12 12:31 ` Eli Zaretskii 2023-02-12 12:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-02-12 13:04 ` Eli Zaretskii 2023-02-12 14:12 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-02-12 14:36 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).