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]

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.

[Martin521]

I added tests now also for multiple edit / typecheck cycles of the same file; fixed a flaw in the warn scope storage; fixed TransparentCompiler where in a certain situation it didn't play well with warn scopes; got FSAC/Ionide working with warn scopes and started explorative testing. So, I am submitting this once more for review.

[T-Gro]

Thanks @Martin521 .
Was any VS testing done after the change?

If not, I will schedule myself for later to test this change applied to VS and check the behavior of the incremental-compilation.
(I already apologize, it can take a few weeks until I get to that - if you can find any other volunteer to test this in VS, I am fine with another evidence (e.g screen recordings))

Unfortunately the editor tooling is not unified via LSP (yet), so there can be subtle differences in how editors react to changes affecting diagnostics :(.

[Martin521]

Was any VS testing done after the change?

If not, I will schedule myself for later to test this change applied to VS and check the behavior of the incremental-compilation. (I already apologize, it can take a few weeks until I get to that - if you can find any other volunteer to test this in VS, I am fine with another evidence (e.g screen recordings))

No, I don't have VS installed.
Any volunteers out there?

[dotnet-policy-service]

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
2. Ask a committer to mail the .NET SDK Breaking Change Notification email list.

You can refer to the .NET SDK breaking change guidelines

[T-Gro]

@Martin521 :

Since the RFC does have a breaking chance section, I decided to pick this PR as our first tester of the new SDK breaking chance policy. You do not have to do anything now, I will test how the labels help us track which doc changes are needed and if the process for documenting changes labelled as potentially breaking works smoothly.

[Martin521]

Since the RFC does have a breaking chance section, I decided to pick this PR as our first tester of the new SDK breaking chance policy. You do not have to do anything now, I will test how the labels help us track which doc changes are needed and if the process for documenting changes labelled as potentially breaking works smoothly.

Let me know I should create a new issue, using the breaking change template, with a pointer to the old one, and link this PR to it.