emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Call for volunteers: add tree-sitter support to major modes


From: Po Lu
Subject: Re: Call for volunteers: add tree-sitter support to major modes
Date: Thu, 20 Oct 2022 08:19:28 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

> This part definitely isn't valid:
>
>   extern maybe_tls (int) errno;
>
>  $ gcc -c buggy_c.c
>  buggy_c.c: In function 'maybe_tls':
>  buggy_c.c:1:26: error: expected declaration specifiers before 'errno'
>      1 |   extern maybe_tls (int) errno;
>        |                          ^~~~~
>  buggy_c.c:1:21: error: parameter name omitted
>      1 |   extern maybe_tls (int) errno;
>        |                     ^~~
>  buggy_c.c:2: error: expected '{' at end of input

Well, what if tree-sitter is given the following macro definition?

#    if !defined (LinkTargetKO) && !defined (__cc_lint__)
#    define maybe_tls(type) _task_local_/**/type
#    else
#    define maybe_tls(type) type
#    endif

> And this:
>
>   BEGIN_A_KIND_OF_SECTION ({
>       ENTRY (dx, dy, shx, shy)
>       float dx, dy, shx, shy;
>
>       if (!bar (other_function (dx, dy, shx, shy),
>               etc, etc, etc))
>       die ("bar", sys_errlist[errno]);
>     }, register float, section_name);
>
> can only be valid C if BEGIN_A_KIND_OF_SECTION does something very
> creative, like expands to nothing at all.  So, for a fair discussion,
> please show the macros used here, and let's see what does tree-sitter
> do when it's shown the macros.

This particular macro is a little too long for me to trim down into a
form I'm actually allowed to send here.  But what happens when
tree-sitter is shown the other macro, maybe_tls?

> Why is that "much worse" than what CC Mode does?  Just yesterday I had
> a perfectly valid C code where CC Mode was unable to fontify several
> function calls correctly.  I attach it below.  You can see it
> yourself: go to line 2000 in treesit.c of the feature/tree-stter
> branch.  Unlike many CC Mode bugs, this one isn't transient: killing
> the buffer and revisiting the file reproduces the same problem.  (This
> problem seems to be solved in Emacs 29, btw.  But I see its like
> almost every day in other situations.)
>
> I'm quite sure CC Mode "succeeds" with your example of invalid C code
> simply by sheer luck.  And what's more important to me is that it
> fails in much simpler, straightforward cases, where I wouldn't expect
> any trouble at all.

Trust me, I have my own bad experiences with CC Mode fontification.  See
the slew of bugs I found and reported with Emacs 29's CC Mode just this
week: bug#58537, bug#58534, bug#58539.  My problem is the blanket
dismissal of what CC Mode actually gets right that seems to be
alarmingly prevalent around here ("... in Emacs 30, let's get rid of CC
Mode!")

> The code you posted didn't include the definition of P_, so how do you
> expect a parser to guess what it is?  Include it in the code, and
> let's see then what happens.

#    ifdef (__cc_check_protos__)
#    define _P(protos...) /**/protos
#    else
#    define _P(protos...)
#    endif

> This is valid C?

It is in this compiler (and C preprocessor), which has not seen major
updates since 1994, and is yet still used by suits.

> And after all that said, I'll trade CC Mode's fontifications for much
> more performant C mode any day, even if the faster mode sometimes
> errs.  The CC Mode's performance is abysmally slow.

> Here's the picture I promised:

I agree that's bad, but so is the tree-sitter fontification of K&R
areas.

According to this ticket, tree-sitter currently doesn't support
them at all: https://github.com/tree-sitter/tree-sitter-c/issues/75.  At
least there is work in that area, but it has not seen activity since
Sept 2021.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]