problems with `>>`; e.g., `cast<TArray<T>>`, or `auto x = 2 >> 1` being detected as bool about vscode-unreal-angelscript

[Lucas7211]

Haha, this is another case where I took shortcuts because of unreal limitations actually.
Unreal doesn't allow directly nested containers at all, so you can never actually get templates deeper than >> in UE-AS scripts, and it's never allowed to cast to a container so we don't have the cast parsing issue.
You can see I also cheated some of the parsing ambiguity by hardcoding the available container types, since at least in our plugin there's a pretty small number of allowable containers that unreal understands.

The bug with parsing 2 >> 1 is concerning though. (Although I can probably count the amount of times we've actually used bit shifts in our game scripts on one hand haha)
I definitely will take a look at your solution, thank you for sharing it!
Although changing the operator parsing is a bit scary. In the past it has been by far the most combinatorially complex part of the rules and makes it really easy to wreck the parsing performance.

[XertroV]

You can see I also cheated some of the parsing ambiguity by hardcoding the available container types, since at least in our plugin there's a pretty small number of allowable containers that unreal understands.

Yeah, I piggybacked on that b/c it's a similar situation with openplanet's flavor. Users can't create new template types, so there's only half a dozen or so to account for.

(Although I can probably count the amount of times we've actually used bit shifts in our game scripts on one hand haha)

Yeah, I figured it wasn't that big a deal since it's a pretty uncommon operation and it doesn't break anything besides the LS type resolution afaik (which has very little impact).

Although changing the operator parsing is a bit scary. In the past it has been by far the most combinatorially complex part of the rules and makes it really easy to wreck the parsing performance.

Good to know it's a bottleneck for parsing performance. I didn't run into that with my testing last night, but I'll keep it in mind.

That reminds me of a pegged 100% CPU bug with my fork (not sure exactly what was looping infinitely but something was) -- after some profiling and a binary search of what code was responsible, this was the solution: (I think the @ at the end was the main thing, just noticed that I added : in there, too)

So yeah, potentially big impacts from small changes.

An alternate solution I thought of was reprocessing the AST output to detect the case of BinaryOp<BinaryOp<left,null>,right> (where .operator == ">" for both) and replacing it with the corrected expression. If you are interested in fixing the type resolution without touching the parser, that might be a less risky method (although a bit hack-y).

[Lucas7211]

I tested it out over here, and it looks like 2 >> 1 is being correctly detected as int for me.
Most likely because the lexer is disambiguating it by parsing >> as one token, which I think you've removed in your fork.

Since the template and cast parsing issues are not possible to trigger for us due to unreal limitations, I'm going to close this issue.
But thank you for taking the time to report it and providing your analysis!

[XertroV]

Most likely because the lexer is disambiguating it by parsing >> as one token, which I think you've removed in your fork.

I have now - but that's pretty recent. I don't know if it was being incorrectly detected before I started fiddling with >> yesterday.
I changed some things earlier when I was trying to get template types working (like a week or more ago), so I might have broken the type detection then without knowing, too (since opShr is pretty rare).

In any case, glad to hear it's not an issue.

I'm going to close this issue.

👍 sounds good.