Fix for issue #341

[Thorium]

The cause of this crash is that there are multiple rules hit for a variable.
Right now what happens: FSharpLint crashes and doesn't produce output.

Instead, if we just ignore the failure of adding a rule failure to a single line of code, the lint-task would produce a result.
After fixing the first issue the end-user can re-run the lint again and see if the earlier ignored rule still hits or not.

[knocte]

@Thorium hi Tuomas, great contribution! Do you mind adding a regression test?

[knocte]

LGTM! Just 2 nits please:

• In the test file, please add EOL before EOF.
• Do you mind changing the order of your commits with interactive rebase? After that, push 1 by 1 (so I can see the 1st one with a red CI, and the 2nd fixing it).

[knocte]

After that, push 1 by 1 (so I can see the 1st one with a red CI, and the 2nd fixing it).

Oh, and for this to really happen, you need to enable GitHubActions in your fork, first (before pushing, after the interactive rebase).

[Thorium]

You can test specific commits just by id git cherry-pick b80db49b7b2f when in master.
But, it turns out I cannot easily replicate the current runtime crash with an unit-test.
So, I removed the test.

[knocte]

You can test specific commits just by id git cherry-pick b80db49 when in master.

But I want GitHub to do it for me :) Can you enable GitHubActions in your fork please?

But, it turns out I cannot easily replicate the current runtime crash with an unit-test.

Mmm, then we should bring some fragment of code from ProvidedTypes.fs like you mentioned in the bug?

[Thorium]

I was able already to fix ProvidedTypes.fs with the following workaround:

• I added custom fsharplint.json where I removed so many rules that it didn't hit many duplicate rules at the same code line.
• Then I fixed the issues it found.
• Observe it's now hitting only single rules, so it can run with default config.

However, as a workaround without this fix, that's a quite un-inviting user experience for new users.

[knocte]

However, as a workaround without this fix, that's a quite un-inviting user experience for new users.

Completely agree, but let's not lose scope here, we're talking about fixing issue #341 here. Can you rescue a previous version of ProvidedTypes.fs that reproduces the bug?

[Thorium]

Can you rescue a previous version of ProvidedTypes.fs that reproduces the bug?

That's miles long. Rather use the code that is in the original issue. But it's not happening while in source-code (as you can see from the issue), rather when using external files only. Which means it should be an integration test and not a unit test. But I don't see the amount of work to add integration tests would be beneficial on resolving the issue.

[knocte]

That's fair enough. I'll then merge this shortly, at least knowing it doesn't break any current tests.

I just need to figure out if I want to merge this before or after next release.