I see that I have 1 failing:

1. workspace-namespace findFiles:
   AssertionError: 0 == 1

   • expected - actual
     -0
     +1

   at C:\projects\vscode\extensions\vscode-api-tests\src\singlefolder-tests\workspace.test.ts:499:11

Is this a know instability or is it using this link pattern matching?
For some reason I cannot debug or run this test. When I do

PS C:\git\vscode> .\scripts\test.bat --run "C:/git/vscode/extensions/vscode-api-tests/out/singlefolder-tests/workspace.test.js"

it hangs and doesn't do anything.

Also, I see that 1 of the 3 travis jobs failed after 50 mins for hanging.
Could these issues be related to my changes?

@DominikDitoIvosevic thanks for your PR.
Great that you have written tests. On top of that you could update the comment above the regex since it is quite complex so to make it easier for understanding.

Travis failing you can ignore. However unit tests you probably broke since they are passing nicely wihtout your changes.
Please look into fixing them.
You can run the unit tests by using the launch configuration "Unit Tests"
Here's our contributing document which should have more info on this subject https://github.com/Microsoft/vscode/wiki/How-to-Contribute

@isidorn I was locally having issues with running tests because I was using the default git checkout style using clrf and your tests are hardcoded to work with LF. I see that after remerging with master my tests pass on appveyor but travis still fails. Does this mean the last fail was an instability and my PR is ok?

I tried allowing spaces in all the file patterns but there seems to be a bigger issue here. You have to choose between more path characters or more variations from which we can extract paths.

One problem is that while on Windows <>" etc are invalid path characters they are valid on linux. Also, one test wasn't catching ] and ' which are valid on all operating systems so I suppose that was a mistake. The reason why the last of the 3 patterns doesn't allow spaces in the path is because you allow for not specifying neither the line nor the character for that pattern and since space is a valid character in the file extension it's not possible to match your current tests.

While I think it's important to support spaces for all path patterns, allowing spaces for the last of the 3 patterns would require you to enforce specifying some character after the path. For instance some tests have in after the path but none of the patterns require the in to be there. We could split the last pattern to allow for neither the line or the char but to require in after the path. That decision is up to you.

@isidorn could you please tell me if there is something else I need to do? Could we get a review started up?
I've split the patterns into template literals to hopefully make it more clear what's going on.

@DominikDitoIvosevic Hi, this week we are in the endgame week, which means we only take limited code changes we are cruical for the release.
Due to that I will review this PR next week in our debt week. Than I will provide feedback. Thanks

@isidorn Does this mean this fix is potentially getting into 1.22 or 1.23?

@DominikDitoIvosevic 1.22

@DominikDitoIvosevic I checked out your changes and they make sense to me. I would merge them in so we try them out in insiders and see if something breaks.
However also adding @alexandrudima since he is the original author looking at commits to see if he objects about some changes here.

@DominikDitoIvosevic did you bild vscode with your changes and verify nothing gets badly broken? Like detecting links in various outputs?

@isidorn Adding @bpasero. He is the original author of the output link computer.

Let's merge this in and see how it behaves in the wild.