Syntax highlighting wrong for one character constants in Rust

[A-Walrus]

Summary

Constants with one character names are incorrectly highlighted in Rust
They both have the same tree-sitter scopes:
Definition: scopes: ["source_file", "const_item", "identifier"]
Usage: scopes: ["source_file", "function_item", "block", "let_declaration", "identifier"]

const NUM: usize = 5;
const N: usize = 4;

fn f() {
    let a = N;
    let b = NUM;
}

Reproduction Steps

I tried this:

1. hx file.rs file with code from above

I expected this to happen:
one letter constant "N" is highlighted the same as other constants

Instead, this happened:
It is highlighted the same as a "type_identifier"

Helix log

Nothing

Platform

Linux

Terminal Emulator

Gnome console

Helix Version

22.08.1

[the-mikedavis]

helix/runtime/queries/rust/highlights.scm

Lines 185 to 186 in 5467c65

	((identifier) @constant
	(#match? @constant "^[A-Z][A-Z\\d_]+$"))

That + should probably be a *, eh?

[A-Walrus]

That + should probably be a *, eh?

I think so.

There is also the question of what to do when people don't conform to the naming standard.
Should:
fn CAPITALIZED() be highlighted as a function or constant (currently it looks like a constant)
same with const lowercase: usize = 0 should it be highlighted as a constant or a variable (currently looks like variable)

both of these cases can be detected with a treesitter query:

(const_item
  name: (identifier) @constant
)

for constants, and a similar one for functions

[kirawi]

We could put it below function calls so precedence handles that.

[gavincrawford]

I'm pretty sure the fix recommended by @the-mikedavis works for this case.

[the-mikedavis]

It's possible to only highlight constants with

(const_item name: (identifier) @constant)

as you say but then you need to use locals tracking to highlight further uses of those const variables correctly. That has problems of its own (#1151) but also it becomes difficult to highlight constants across files:

use helix_core::surround::PAIRS;

log::info!("{:?}", PAIRS);

would be ambiguous. It's something that could probably be done correctly with enough smartness - maybe stackgraphs. I think that highlighting constants only by naming conventions works well enough though.