GNU bug report logs - #74277
29.4; rust-ts-mode doesn't highlight some function calls

Previous Next

Full log

Message #26 received at 74277 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Randy Taylor <dev <at> rjt.dev>
Cc: acidbong <at> tilde.club, Trevor Arjeski <tmarjeski <at> gmail.com>,
 74277 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#74277: 29.4; rust-ts-mode doesn't highlight some function
 calls
Date: Sat, 23 Nov 2024 21:18:58 -0800

> On Nov 21, 2024, at 7:30 PM, Randy Taylor <dev <at> rjt.dev> wrote:
> 
> On Wednesday, November 20th, 2024 at 13:22, Trevor Arjeski <tmarjeski <at> gmail.com> wrote:
>> 
>> Trevor Arjeski tmarjeski <at> gmail.com writes:
>> 
>> 
>> I decided to hack around with this a little bit and found that adding
>> the following lines partially works:
>> 
>> 
>> I'm sure there is an issue with solving it this way, I just need someone
>> else more experienced to confirm. It is finicky where it turns the
>> highlighting on and off when you make some code changes, for example
>> adding and removing the semi-colon after the macro invocation.
> 
> Yuan would be the best to answer that.

Using injection (what Emacs calls local parser, same thing) here is fine, I think. As Randy said, tree-sitter doesn’t have a good answer for macros. If nvim uses this workaround (create an injection for the macro and parses it like normal rust code), then it should be fine for us to follow suit.

> 
> Personally, I envisioned a custom highlight helper function like
> rust-ts-mode--fontify-pattern or rust-ts-mode--fontify-scope which
> seems like the simplest solution that should cover this use case, but
> I'm not actually aware of all the sorts of craziness one could get up
> to in a macro invocation so that might not be enough and maybe injections
> are the way to go.

Rust macros are not as crazy as C/C++, but definitely goes beyond normal rust code, for example, the select! macro:

#[tokio::main]
async fn main() {
    tokio::select! {
        _ = do_stuff_async() => {
            println!("do_stuff_async() completed first")
        }
        _ = more_async_work() => {
            println!("more_async_work() completed first")
        }
    };
}

Does what you envisioned work for something like this? To be fair, I don’t think the injection solution works well for this either.

Yuan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.