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

[Randy Taylor]

On Wednesday, February 8th, 2023 at 10:44, Dmitry Gutov <dgutov@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
Description: Text Data