highlights: rust: adjust enum variant recognition

[rosefromthedead]

Now, enum variants with no arguments are recognised:

match x {
    Here => {},
}
ErrorKind::Here.clone();
module::Enum::AndHere.into();

and have been tested to not be falsely recognised:

Here.clone();
module::OrHere.into(); // probably unit structs, not variants

but still aren't recognised in the absence of a field access, method call or match arm because I think we'd need to put a PascalCase::PascalCase rule for that everywhere where expressions can appear (to rule out unit structs) which is likely possible but definitely annoying.

[kirawi]

So, the reason why I settled on highlighting these as @constructor is that there is ambiguity between destructing structs and enums. For example,

match x {
    // Can either be a struct or an enum with named fields
    Foo { a, b, c } => {}
    // Can either be a tuple struct or an enum with fields
    Bar(a, b, c)
}

[rosefromthedead]

You're right that there's ambiguity, and I see these ways out of it:

1. Give up on @type.enum.variant. Anything with PascalCase in expression or pattern position would be a constructor, but the same idents in type position would remain as @type.
2. Try to improve heuristics so that @type.enum.variant is correct as often as possible. IMO the current situation where the match pattern Some(x) is an enum variant but the match pattern None is not is surprising to look at, which is why this PR is here, but there is still more work to do to get this right.

I was originally aiming for (2), but (1) would be a lot more robust and more concise to implement, and I think I'd still be happy with a theme based on that :) so I'll give it a go.

[kirawi]

I don't feel like this is quite the right away to approach this because now it creates further ambiguity between enums and structs outside of pattern matching. I think the most correct way to address this is to have locals.scm track enums in a file (and potentially use stackgraphs in the future) and use semantic highlighting from the LSP, the latter of which has an implementation in an old PR: #6102

I have been meaning to get to it, but life has been busy. But, it should fix your issues with the inconsistent highlighting once I or someone else continues that work. This PR, if merged, would likely need to be at least partially reverted in that case for proper token tracking.

[kirawi]

Except for this change, I am fine with the rest of the PR (since it is technically used in the form of constructors) as long as these changes are tracked to be possibly at least partially reverted once semantic highlighting is implemented. I don't know what the other maintainers think though.

[kirawi]

Are you still interested in this PR? The comment before my last one may have given the idea I was rejecting the change all together, which is not the case.

[rosefromthedead]

Thanks for the poke, I had just forgotten :)