GNU bug report logs - #61302
29.0.60; rust-ts-mode does not show function-invocation on field-properties

Previous Next

Package: emacs;

Reported by: jostein <at> kjonigsen.net

Date: Sun, 5 Feb 2023 20:16:01 UTC

Severity: normal

Found in version 29.0.60

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Randy Taylor <dev <at> rjt.dev>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: eliz <at> gnu.org, Jostein Kjønigsen <jostein <at> kjonigsen.net>, 61302 <at> debbugs.gnu.org
Subject: bug#61302: 29.0.60; rust-ts-mode does not show function-invocation on field-properties
Date: Thu, 09 Feb 2023 03:38:59 +0000
[Message part 1 (text/plain, inline)]
On Wednesday, February 8th, 2023 at 10:44, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>On 08/02/2023 05:38, Randy Taylor wrote:
>> I think the following rule from the type feature:
>> (scoped_type_identifier path: (identifier) @font-lock-type-face)
>>
>> Should be changed to font-lock-constant-face and moved to the module feature.
>>
>> That way, things like the following will be highlighted correctly:
>> let date = DateTime::<chrono::Utc>::from_utc(date, chrono::Utc);
>>                        ^^^^^^ this guy
>>
>> Unless I'm missing something.
>
>Should Utc in the above example be highlighted with
>font-lock-constant-face too?

No. It's a type.

>
>What if it looked like this:
>
>   let date = DateTime::<chrono::utc>::from_utc(date, chrono::utc);
>
>If we decide purely based on capitalization, then I guess the rule
>should be present in both lists (with capitalized? regexp in one, and
>!capitalized? regexp in another), and a few more rules should be
>duplicated as well.

In both cases, utc is still a type even if it's not capitalized.
My patch addresses this.

>
>This becomes a little more painful semantically, given that the first
>'utc' in the example above is parsed into a (type_identifier) node, not
>just (identifier).
>
>>> On a distantly related note, we have terms like 'usize' which is
>>> normally a type (and highlighted as such), but can also feature in
>>> expressions like
>>>
>>>    let row = usize::from_str_radix(row, 10).map_err(|_| error())?;
>>>
>>> where it is now highlighted with font-lock-constant-face. Should we try
>>> to do anything about that? If there is a limited number of built-in
>>> types in that situation (e.g. all of them primitives), we could handle
>>> that with a regexp.
>>
>> Right. I think it makes sense to handle the primitives with a regex.
>> I'm not sure if there's anything else beyond those.
>> There's a list of them here: https://doc.rust-lang.org/reference/types.html
>> I think it would only apply to the numerical and textual types.
>
>So 'usize' in the above is definitely a "type", not a "module"?

I think so. You can see on usize's documentation page (https://doc.rust-lang.org/std/primitive.usize.html)
that it provides that function, amongst many others.

>
>>> Or vice versa, in
>>>
>>>    use std::{fmt, fs, usize};
>>>
>>> should 'fmt', 'fs' and 'usize' be highlighted with
>>> font-lock-constant-face rather than font-lock-type-face?
>>
>> They should indeed be highlighted with font-lock-constant-face because they are modules.
>> We assume the types will be capitalized since that's all we can really do (and it's the convention anyway).
>
>If they're modules here, I suppose they should be highlighted the same in
>
>   let row = usize::from_str_radix(...)
>
>as well. The bright side is that will make a more complex regexp
>(enumerating the lowercase named types) unnecessary.

Yes, except for the primitives.

I have attached a patch which I think addresses most of the concerns (although I've been at it for a few hours and my brain is mush now).

The patch does the following:
- Separates import-related stuff and module use by leveraging the use_declaration query (simplifying things greatly IMO).
- Highlights primitive types used in scoped_identifiers.
- Properly highlights types belonging to a module no matter how deep it is (or your money back guaranteed!).
- Maybe some other stuff I forgot. I'm too tried now :).

A few questions:
- Should module be moved to level 3 to be with type?
- Do we still want the module feature, or should this stuff be put into type?
[0001-Fix-rust-ts-mode-type-and-module-highlighting.patch (text/x-patch, attachment)]

This bug report was last modified 2 years and 91 days ago.

Previous Next


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