Generate expressive diagnostic messages with the offending line

[wilzbach]

A very naive implementation to ask on feedback on this before I invest more time in this.

Questions

1. Should we save the originally opened file (it's currently thrown away by default)? Re-opening them has the advantage of only paying this overhead in an error case.

2. Under which CLI flag should this be exposed?

3. Is there a chance that we can do sth. similar like we do with the coloring? Only if dmd is run in a terminal, turn of the expressive diagnostics by default if dmd, but still have flags to control the behavior manually

Clang calls this "expressive diagnostics" and there's a lot more cool stuff that we can do.

Motivation

Compiler error for humans sums it up pretty nicely.

Also note that all three major C++ compilers (Clang, GCC, MSVC) have such expressive diagnostics enabled by default. It's time for DMD to catch up with the modern era.

[dlang-bot]

Thanks for your pull request, @wilzbach!

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 fetch digger
dub run digger -- build "master + dmd#8487"

[jacob-carlborg]

I like it. Would be nice to have as default.

I’ve been thinking about fixits that Clang has as well. This would be especially useful for deprecations that usually contains a suggestion how to fix it.

[PetarKirov]

For inspiration see also

• https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html
• http://www.jonathanturner.org/2016/08/helping-out-with-rust-errors.html
• Error code list which need to be updated to new format rust-lang/rust#35233
• Error Message Overhaul rust-lang/rust#33240
• https://doc.rust-lang.org/error-index.html
• https://mobile.twitter.com/b0rk/status/954366146505052160

[wilzbach]

I'd add a test with mixin() and mixin template

Added. For simplicity, I don't do the pretty printing for mixins for now though.

Would be nice to have as default.

Yeah that's my goal too!
However, before we make it the default, I think we should have it as an opt-in for two or three releases, s.t. we get enough feedback/testing.

[WalterBright]

I want to thank @wilzbach for finding a way to do this that doesn't involve changing 30 or 40 files :-) I like that the implementation is pretty encapsulated. When other PRs cross-cut through the files, it shows how poorly encapsulated the compiler internals are.

1. Reopen the file for printing errors. (Otherwise, keeping the files around consumes a lot of memory.) But once it is reopened for error messages, cache it in a buffer.)

2. I'd rather the switch be "context" rather than "pretty". Pretty-printing usually refers to a function identifier being expanded to printing the whole declaration.

3. I don't think it being in outputting to a tty should change this behavior.

[On a personal note, I am annoyed by this, for the simple reason that the DMC C compiler has done the line with the caret since 1982, and not a soul ever cared for the feature or even mentioned it. So I dropped it for DMD. Suddenly, it's the height of fashion, innovation and modernity to have it, and I'm 180 degrees out of phase. Sigh.]

[WalterBright]

In case I wasn't clear, yes, let's move forward with it.

[wilzbach]

Added a simple line-by-line cache, but before I figure out how to add it to all the makefile, it would be good to know if this should live in a separate module or somewhere else.

[andralex]

cc @WalterBright

[jacob-carlborg]

I think we should avoid module constructors.

[wilzbach]

Removed the module constructor, but now we need to manually initialize in mars.d / frontend.d

[ibuclaw]

Moving forward post this pr, it would be really nice to have location ranges (start and end locations for all expressions).

[wilzbach]

Rebased this PR. It's still behind the -verrors=context flag, so that we can get some real-world feedback before we enable it by default.

[thewilsonator]

Since the addition of -mixin=<filename> might want to doublecheck that logic.

[wilzbach]

Good point. For now, I just added && !global.params.mixinOut as that's definitely safe.
In the future, we probably need to call flushMixins or make the fileCache aware of mixin files.

[wilzbach]

Ping @thewilsonator. Anything blocking this PR?
It's not enabled by default yet and it would be great to gather some real-world feedback with the next release / nightlies.