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.