Implementation of a diagnostic reporting message style for the dfa engine

[Iskaban10]

The pull request implements a diagnostic reporting mechanism fir the dfa engine. Most of the code has been taken from here.
The following code when run with -verror-style=diagreport

int bar(float v) => cast(int)v;

enum FooBar = Foo!null;

template Foo(alias Val) {
  enum Foo = bar(Val);
}

produces this result

@rikkimax @thewilsonator

[thewilsonator]

see the CI for trailing whitespace and newline missing at end of file.

[dkorpel]

We shouldn't bolt on a whole new error printer with a compiler switch. Improvements should be integrated into existing usage.

[rikkimax]

We shouldn't bolt on a whole new error printer with a compiler switch. Improvements should be integrated into existing usage.

We have multiple styles already.

To integrate it into an existing style essentially means replacing it.

[dkorpel]

We have multiple styles already.

Which is already a shame, let's not make it worse.

[rikkimax]

We have multiple styles already.

Which is already a shame, let's not make it worse.

Okay I'm not necessarily against it. Have at it!

[dlang-bot]

Thanks for your pull request and interest in making D better, @Iskaban10! 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#23115"

[Iskaban10]

We shouldn't bolt on a whole new error printer with a compiler switch. Improvements should be integrated into existing usage.

Should I integrate this message style in the -verrors=context? It stays integrated with the default error printer in that case

[dkorpel]

The first course of action would be to split up the PR in well-defined issues focusing on 1 thing at a time. Currently it's doing so many things at once (new coloring, line numbering, grouping, multiple carets, and more) that it becomes intractable to review.

[rikkimax]

Most of this PR kinda has to go together, otherwise it's basically a new implementation of the logic in each PR doing a step of it. Not a good idea.

I think a first good PR, then maybe the grouping of messages/supplemental and doing a delay write. No other changes.

Basically, focus on putting the events into a form that can be sent to the drawing algorithm.

[dkorpel]

Most of this PR kinda has to go together, otherwise it's basically a new implementation of the logic in each PR doing a step of it. Not a good idea.

It's hard to tell, this PR currently closes no GitHub issues, has no tests, no changelog - there's no complete picture of what it does. The goal is not to split up the 1300 lines of new code, but to identify actual issues before coming up with a solution.

[Iskaban10]

Most of this PR kinda has to go together, otherwise it's basically a new implementation of the logic in each PR doing a step of it. Not a good idea.

It's hard to tell, this PR currently closes no GitHub issues, has no tests, no changelog - there's no complete picture of what it does. The goal is not to split up the 1300 lines of new code, but to identify actual issues before coming up with a solution.

I have committed a few changes as of now. Only the functions which collect the diagnostics and delay the printing are present in errors.d. Also a few file changes related to -verror-style=diagreport flag are present.

[dkorpel]

Thanks, it's now a lot clearer what this PR does. However, I still don't see why you need to add a MessageStyle and collect diagnostics in a global array in errors.d, as there's still no linked GitHub issue, test, or documentation.

[Iskaban10]

Thanks, it's now a lot clearer what this PR does. However, I still don't see why you need to add a MessageStyle and collect diagnostics in a global array in errors.d, as there's still no linked GitHub issue, test, or documentation.

Well the global array to collect diagnostics was already present for the sarif messagestyle here. It is used by the addSarifDiagnostic function in sarif.d

[dkorpel]

What issue is this PR trying to solve?

[Iskaban10]

What issue is this PR trying to solve?

This was a post long back by @rikkimax on improving dmd's error output for his dfa engine here. This PR is an implementation for it based on this gist by him.

[dkorpel]

That post says:

The reason I am exploring this is for the fast DFA engine, assuming it gains tracing support.

Let's wait until something like that actually gets implemented, because it's really hard to review code that's supposed to solve a problem that doesn't exist yet!

[dkorpel]

Well the global array to collect diagnostics was already present for the sarif messagestyle here. It is used by the addSarifDiagnostic function in sarif.d

That turns out to be completely unnecessary, I'm working on removing it: #23176

[rikkimax]

That post says:

The reason I am exploring this is for the fast DFA engine, assuming it gains tracing support.

Let's wait until something like that actually gets implemented, because it's really hard to review code that's supposed to solve a problem that doesn't exist yet!

Yes, the engine would require additional integration to trigger it. That isn't in the scope of this PR.

What Iskaban was very kind to offer to do, was to integrate it into error reporting of the compiler as a whole, so that we get improved error messages.

That portion has been approved in a monthly meeting as its own style.

By itself, it is already valuable work, as it brings dmd inline with other mainstream compilers in giving more context to our errors.

[dkorpel]

improved error messages

#23115 (comment)

[rikkimax]

I have not filed an enhancement request.

I can if you want a dummy one, but it'll basically just boil down to the same information printed differently, aligned with some mainstream compilers.