Long lines cause slow syntax highlighting and VS Code to hang

[lucarottoli]

The last version of Modern Fortan seems to have issues with some files. VScode becomes unresponsive and several minutes are needed to be able to navigate the file. I am experiencing issues on MacOS.

Attached a .f90 file which triggers such a behaviour.
coefficient_functions.f90.zip
.

[gnikit]

Which version number introduced the issue?

[lucarottoli]

From what I can tell, v2.6.2 (I started to experience such a problem last week when it updated, but I might not have opened the incriminated file till earlier).

[gnikit]

I would suspect that the issue is related to the 2k+ columns some lines have which could result into the regex of the language grammar to fail. v2.6.2 did not alter the grammar files. Can you try and provide a more minimal example where the bug is encountered, ~950 lines is a bit too big.

[gnikit]

Yeah so commenting out the long res lines, opening the file and then uncommenting line 258-260 causes the extension to break. I suspect that I added a regex for something that is extremely inefficient for long lines

[gnikit]

Specifically the bug shows up when you have a line with +1k columns

MWE

Un/commenting the last line will cause VSCode to crash.

program bug
    implicit none

         res = (CF*(28*nf + CA*(-202 + 189*Zeta3)))/27./(one-x) + & ! this is the regular part of the plus distribution 1/(1-x)_+
              ! now add the regular terms
               & (CF*(-344 + 24*Pi**2 + 974*x - 1600*CA*x + 1188*CF*x - 432*CA*HPL30*x + 1080*CF*HPL30*x + 148*nf*x - 60*Pi**2*x + 54*CA*Pi**2*x - 54*CF*Pi**2*x - 1188*x**2 + 1584*CA*x**2 - 2376*CF*x**2 - 72*nf*x**2 + 72*Pi**2*x**2 - 108*CA*Pi**2*x**2 + 108*CF*Pi**2*x**2 + 830*x**3 + 16*CA*x**3 + 1188*CF*x**3 - 432*CA*HPL30*x**3 + 1080*CF*HPL30*x**3 - 76*nf*x**3 - 60*Pi**2*x**3 + 54*CA*Pi**2*x**3 - 54*CF*Pi**2*x**3 - 272*x**4 + 24*Pi**2*x**4 + 216*(CA - CF)*HPL31*x*(1 + x**2) + 1188*CA*x*zeta3 - 1080*CF*x*zeta3 - 324*CA*x**3*zeta3 - 1080*CF*x**3*zeta3 - 36*CA*Pi**2*x*log(1 - x) + 36*CF*Pi**2*x*log(1 - x) - 108*CA*x**2*log(1 - x) + 108*CF*x**2*log(1 - x) + 108*CA*x**3*log(1 - x) - 108*CF*x**3*log(1 - x) - 36*CA*Pi**2*x**3*log(1 - x) + 36*CF*Pi**2*x**3*log(1 - x) - 252*x*log(x) + 348*CA*x*log(x) - 540*CF*x*log(x) - 60*nf*x*log(x) + 612*x**2*log(x) - 432*CA*x**2*log(x) + 1404*CF*x**2*log(x) - 744*x**3*log(x) + 996*CA*x**3*log(x) - &
               1728*CF*x**3*log(x) - 60*nf*x**3*log(x) + 384*x**4*log(x) - 144*log(1 - x)*log(x) + 360*x*log(1 - x)*log(x)))
end program bug

Additional info

Introduced in vesion v2.4.0

[lucarottoli]

Thanks - I imagined it could be related to that. Do you suggest to try editing the files and break the lines, or do you plan to address the regex issue for such files?

[gnikit]

I will have a go at trying to locate the bug in the syntax highlighting. I have also noticed that for large files our syntax highlighting is slower than what it used to.

If I had to make a guess I would say that the issue stems from the highlighting rules for nested statements
function (function, var) result(var). IMO the standard should not permit Fortran keywords to be used as variable names, that would make our highlighting regexs substantially simpler and consequently faster.

[lucarottoli]

I noted in the past that long/large files could cause slowdowns, but personally I only noticed in files with long columns (even before the update which cause VS code to hang completely)

[gnikit]

To be honest that is expected behaviour after a point. Complex regular expressions are rarely scalable with a large number of characters. The tools that we use/develop assume reasonably written code. That is one reason why formatting standards exist.

[lucarottoli]

I agree and in my codes I respect formatting standards - though code that I use/develop on top might not be always written reasonably. Long mathematical expression are anyway tricky to format properly (without inserting mistakes) if they come from outputs of other codes.

[gnikit]

I understand, but I am afraid that there is not much that can be done. I will try and see what change in the highlighting introduced the bug and if there is anything that can be done to limit the problem.

[maxime-rey]

Hey, I am experiencing the same thing.
I have a namelist with a 3746 characters long parameter and it freezes up with this extension when I try to do anything with that parameter. For test purposes I tried splitting it up in smaller lines and it worked better. When I added characters, it became increasingly slower, totally freezing at some point.
When I tell vscode to consider it as a plain txt for example and not fortran, it works perfectly fine.

[gnikit]

I still haven't found time to work on this but the simplest fix that I've thought would be to keep the old syntax and any users experiencing issues would revert to that. The old highlighting would be noticeably less complete but it would not freeze at least.

If anyone is interested to troubleshoot the PR that introduced the bug is #244 and the file that needs inspection is syntaxes/fortran_free-form.tmLanguage.json all the cpp and preprocessor stuff can be ignored.

[thijssteel]

For anyone struggling with this: I notice significant improvement on this issue in the pre-release version (3.0).

[gnikit]

That is interesting, thanks for the heads up. TBH the horrible performance is because of how VSCode evaluates recursive REGEX patterns when it comes to highlighting, e.g. integer function foo(function, arg) result(val).
Supporting highlighting for something like this, effectively means that you have to parse, each line at least twice. The parsing action does not scale well with the string size i.e. length of line so it leads to this slowdown.

I am seriously considering removing support for such syntax patterns, since it is causing so much grief. I really don't see another (reasonable) way out of this.

[gnikit]

Hi @lucarottoli @thijssteel @thijssteel this has now been fixed and will be in the upcoming release of 3.0.
Might take a while, a few days probably, for the v3.0 release because we are still waiting for Microsoft to make some changes to our publisher ID