Improved resilience of formatter_for

[scohen]

It's possible that the call to Mix.Tasks.Format.formatter_for_file can cause a compile or syntax errors. Because these types of errors don't have a message key, the attempt to log them will fail, and the server will crash.

This PR uses Exception.message to build the message text, which should work on any exceptions.

[scohen]

@lukaszsamson With respect to patch:
You pointed out it's another library, and that it prevents async: true.
I tried to exercise the syntax / compile errors "naturally" by building a project structure, and then placing an invalid .formatter.exs in there. This worked, but was easily 30 lines of code, and because I had to cd into the directory to get the call to Mix.Tasks.Format.formatter_for_file to recognize the .formatter.exs, the test was fragile, and was also not capable of async anyways. Even isolating the test in another file (as I have done above) didn't fix the problems that cd caused.

I would have been able to pass an option to formatter_for_file, to explicitly state which .formatter.exs to use, but formatter_for doesn't allow an option to be passed (and I'm pretty sure it's not reasonable to allow that anyways).

The options before me are:

1. Leave this untested.
2. Add an opts keyword list to formatter_for just for testing.
3. Add patch

1 is not an option, because that's how we got into this situation
2 means that the testing code takes a different path than the actual code, which means the actual code isn't really getting tested properly.
3 means we add a library

I think 3 is the best option because it's a small, focused, high-quality library that makes these types of tests much easier to write, which is a good thing. Careful use of patching allows hard-to-exercise code paths testable with only a few lines. It's also a test-only dependency and has not runtime impact.

If you have a better suggestion than patch, I'm all ears.

[lukaszsamson]

OK, I'm convinced that option 3 is the one to go here. Especially if async: false tests are separated.

[scohen]

yay! Thank you, @lukaszsamson

[lukaszsamson]

@scohen are you aware if patch is working correctly on older erlang/elixir combos? Some tests are failing on 1.11 and 1.12, see https://github.com/elixir-lsp/elixir-ls/actions/runs/3229860195/jobs/5287630105. It states that elixir >= 1.7 is supported

[scohen]

@lukaszsamson i talked to the author, and it was developed under 1.11 and 1.12, so it should work. If the problem persists, he asked that you open an issue and he’s be happy to help fix it.

[scohen]

It's also interesting that the error seems to indicate that the patch isn't being applied.

[scohen]

@lukaszsamson I figured it out, see #749