Scoped nowarn

[Martin521]

Description

Implements Scoped Nowarn according to draft RFC FS-1146.

This PR has taken a while. I had to deal with much more complexity than I imagined when I naively volunteered to tackle the feature request. Anyway, here we are.

I have split the PR into 7 commits that can be reviewed in sequence.
All of them compile, 1 and 4 - 7 also pass all tests locally.

1. Add the feature flag, baseline tests, and the core WarnScopes module. See src/Compiler/SyntaxTree/WarnScopes.fsi and the RFC for the functionality of the module.

2. Add the necessary changes to lexing and parsing. Note that the warn directives can no longer be collected during parsing (since they can now appear not only in top-level modules, but anywhere). So we collect them during lexing, similar to the processing of #if/#else/#endif directives.

3. Remove legacy #nowarn processing (but hold off AST changes)

4. Integrate the WarnScopes functionality and test it

5. Add warn directive trivia (but hold off AST changes)

6. Enable warn directive trivia (which means AST changes)

7. Remove defunct types and parameters related to former #nowarn processing (more AST changes)

There is also a separate commit for the IlVerify baseline updates (change in line numbers only)

Checklist

• Test cases added
• Performance benchmarks added in case of performance changes
• Release notes entry updated
• Create documentation update PRs (see RFC)

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/9.0.300.md
LanguageFeatures.fsi	docs/release-notes/.Language/preview.md

[psfinaki]

Hi @Martin521 - thanks for the contribution. It's a substantial effort and we appreciate it. The PR is on our radar - just keep in mind that it's big and specific, and it will take time to find capacity for it.

If anyone from the community gets to thoroughly review it, that would be valuable as well.

Thanks for your diligence and patience :)

[Martin521]

Ok, I have added various compiler service and AST tests that should safeguard the editor behavior.
The three unsuccessful CI checks are obviously failing for reasons not related to this PR.
I would now declare this PR ready for review.

[T-Gro]

Ok, I have added various compiler service and AST tests that should safeguard the editor behavior. The three unsuccessful CI checks are obviously failing for reasons not related to this PR. I would now declare this PR ready for review.

This is great news @Martin521! I will set aside some time during April to review this fully.

[T-Gro]

Hi @Martin521 , I am reviewing + testing this branch incl. editor scenarios today.
One thing I wanted to do as a test exercise is to visit existing code locations with a file-wide "nowarn", delete them, and apply nowarn+warnon locally.

However, when I removed the top level old-style "nowarn", nothing happened - no warnigs!

I then had to make some other tweaks, such as adding a pair of "nowarn"+"warnon" somewhere in the file, for the actions to really happen. Once I broke this initial staleness, it all worked fine from there.

So there is this special scenario where the removal of a single old-style "nowarn" does not do anything.
Since this might be the first introduction scenario for many (replacing old-style "nowarn" with scoping), would you mind taking a look if there could be a caching issue or other form of error causing this?

Video attached:

NoWarn.mp4

[T-Gro]

More focused video on the same problem, it might give you some hints on what triggers a change perhaps?

NoWarn2.mp4

[Martin521]

Thanks for testing! I actually came across a similar "startup" issue when testing with Ionide a few days ago. I have an idea what the cause might be and will find out. It will take a few days though since I am travelling.

[Martin521]

It seems that due to my initial focus on the compile (fsc) use case I didn't cover all editor use cases properly. It won't be so difficult to fix this, but it will take some time. Therefore, I will make this PR draft again. Sorry for prematurely asking for review.

[T-Gro]

No need to apologize :).
I would suspect the changes around removal of ApplyNoWarnsToTcConfig in FSharpCheckerResults. I know that things are done differently after this PR, but there is probably something causing the diagnostic chain to get stale.