[NETBEANS-5024] add support for generics angle brackets

[jherkel]

Original issue https://github.com/apache/netbeans/issues/5024

This fixes a generics angle bracket highlighting. It works for a multichar token like GTGT and GTGTGT. It ignores logic and arithmetic operators. As we need to distinguish between these two cases, java parser is used for this check. I added also unit tests. There is a similar commit https://github.com/apache/netbeans/pull/8500 but I don't think it can work in this way and there is no other activity since May 2025.

[mbien]

you formatted the whole file unfortunately :(

We typically avoid doing unnecessary whitespace changes and limit them to the rewritten sections. (A few fixes here and there are ok, e.g same method)

[jherkel]

Sorry for that. I started with some debuging and some experiments and unfortunately I had a different formatting options. So after some time I realized that I had something that works but the source file was full of debug outputs and temporary code with a wrong formatting. So I tried to reformat the whole code as an attempt to fix it...

[matthiasblaesing]

For anyone wanting to have a look, this branch has an additional commit revering the unnessary whitespace changes: https://github.com/matthiasblaesing/netbeans/tree/pr-8834

[matthiasblaesing]

Outside this PR was the comment:

https://github.com/apache/netbeans/commit/c77d09eda1927adb41107a9eee49fd1fcc504cfd use correct return (null for no match)

I chose this {-1,-1} because I didn't want to change the color of '<' or '>' characters. So I checked the Netbeans sources and I found out that there is {-1,-1} used for an invalid span (it works, but I'm not 100% sure if it is correct). Because null here is used when an opening or a closing element doesn't exist.

Ok, I understand. That needs a comment though if kept. The correct solution would be to return null from findOrigin for the cases where you would return {-1,-1} from findMatches.

Cite from findOrigin:

Returns: The starting and ending offset of the original area or null if the matcher can't detect the origin area within the lookahead distance. If null is returned the infrastructure will never call the findMatches method on this instance.

[matthiasblaesing]

@lahodaj @mbien this looks sane to me. Would you mind having a look?

[jherkel]

I checked source code and the problem here is that as @matthiasblaesing mentioned a parser returns INT_LITERAL for offset position 139 that contains '>' character. Output from lexers is:

T[50]: "int" F(3) INT[29] FlyT, la=1, @2bb62414
T[51]: " " F(1) WHITESPACE[124] FlyT, la=1, @6aecbb8d
T[52]: "n1" <132,134> IDENTIFIER[1] DefT, la=1, @51ac12ac
T[53]: " " F(1) WHITESPACE[124] FlyT, la=1, @6aecbb8d
T[54]: "=" F(1) EQ[84] FlyT, la=1, @565b064f
T[55]: " " F(1) WHITESPACE[124] FlyT, la=1, @6aecbb8d
T[56]: "10" <137,139> INT_LITERAL[64] DefT, la=1, @1fb2eec
*[57]: ">>" F(2) GTGT[108] FlyT, la=1, @1698fc68
T[58]: " " F(1) WHITESPACE[124] FlyT, la=1, @6aecbb8d
T[59]: "1" <142,143> INT_LITERAL[64] DefT, la=1, @463afa6e
T[60]: ";" F(1) SEMICOLON[80] FlyT, @25b2cfcb

Important line is T[56]. It has a position [137-139) (close-open interval) and from my point of view it is correct. But as for above mentioned, javac returns INT_LITERAL. I tried to debug source code (TreeUtilities.java 402-433 lines) and I'm not sure about this line if (startPos < pos && endPos >= pos) {

If I understand correctly, this checks if current three path encloses offset position. But If the position interval is close-open maybe this condition should be if (startPos <= pos && endPos > pos) {

But I'm not sure here. Maybe someone who understands javac internals can clarify this. If I used the second version I could see correct behavior for "int n2 = 10>> 1;" but some unit tests for Java Source Base failed. Right now I'm not sure what exactly is wrong. Does anybody have anu idea?