Move global variables related to diagnostics into a separate struct.

[thewilsonator]

Many modules import dmd.globals; to access only a set of these fields. This will enable further refactoring to both restrict imports of dmd.globals and to pass these parameters explicitly.

[dlang-bot]

Thanks for your pull request and interest in making D better, @thewilsonator! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#17007"

[thewilsonator]

Please doublecheck that I have not messed up the headers

[RazvanN7]

I feel kind of uncomfortable to merge this without seeing what the next changes will look like. Are we going to have to pass a diagnostics object to all of the functions that use any sort of diagnostic? Shouldn't this be somehow part of the ErrorSink interface?

[thewilsonator]

Example: 12567e5
There would obviously less foo(..., global.diag) references and more foo(..., diag) the more it is used.

Are we going to have to pass a diagnostics object to all of the functions that use any sort of diagnostic?

Not a requirement, my initial goal is to remove as much explicit reference to global.foo as possible.
We could indeed turn .error("foo") into diag.error("foo"), but that can wait.

Shouldn't this be somehow part of the ErrorSink interface?

I was originally going to move errorSink[Null] into Diagnostics as well, but I don't quite understand when one should use .error() vs sc.errorSink() and I wanted to keep this PR (relatively) small.

Also note that the state of Diagnostics is effectively singleton, whereas there are two different ErrorSink (ErrorSinkCompiler, ErrorSinkNull) used by DMD, not to mention others (ErrorSinkLatch, ErrorSinkStderr plus any DMD as a Library users), and duplication state between them (or only in one of them) is not really desirable.

[dkorpel]

Example: 12567e5

This doesn't look like the right direction to me. The goal is not to replace global.errors with local.errors, but to replace the whole error-counting gagging system with assigning a different error sink to a gagged scope.

I was originally going to move errorSink[Null] into Diagnostics as well, but I don't quite understand when one should use .error() vs sc.errorSink() and I wanted to keep this PR (relatively) small.

.error in semantic analysis should be replaced with sc.error as much as possible.

Also note that the state of Diagnostics is effectively singleton, whereas there are two different ErrorSink (ErrorSinkCompiler, ErrorSinkNull) used by DMD, not to mention others (ErrorSinkLatch, ErrorSinkStderr plus any DMD as a Library users), and duplication state between them (or only in one of them) is not really desirable.

dmd's error configuration parameters should eventually just be in ErrorSinkCompiler. Shared state between gagged and non-gagged sinks can be in a common ancestor class.