Add ability to emit errors in json + capture symbol name in error_entry

[vanceism7]

Main Changes

• Added a cli flag json-errors

This will cause error_entry.print to print out its errors as a json string instead of a flat string. The flag is mutually exclusive from the -fo flag, i.e: if it's set, it will override the behavior of -fo even if -fo is present.

(Perhaps we should add an error message in if both are set?)

• Add a symbol field to error_entry

I noticed I needed to know the name of the symbol/identifier listed in the error (when it's present) so I know the length to make the little error squiggle. Initially, I was just parsing it out of the error message (with regex) on the language-server side, but later was able to just add the extra field into error_entry so that we can avoid that. I don't know if symbol is the most appropriate name, so I can change if we think something else works better.

---

Other thoughts/context

The ugly aspect of these changes in my mind is that the errors are emitted as a bunch of json objects separated by newlines. The pedantic/purist might argue it would be better if all the errors were actually put into an actual json array so the whole thing could be parsed in one fell swoope, but I surmise this is probably more trouble than its worth. It's easy enough in the language server to split the string into lines and then parse each line individually, e.g:

errors.split(/\r?\n/).map(tryParseJson)

If anything looks off, I'm happy to fix!
Thanks!

[gregmarr]

The ugly aspect of these changes in my mind is that the errors are emitted as a bunch of json objects separated by newlines.

So, JSON Lines format. :)
https://jsonlines.org/

[vanceism7]

The ugly aspect of these changes in my mind is that the errors are emitted as a bunch of json objects separated by newlines.

So, JSON Lines format. :) https://jsonlines.org/

Lol I suppose so haha. I've never heard of the jsonlines format, but it makes sense! (Discovered/used out of laziness on my part lol). Although I don't know that its even necessarily jsonlines, since when I parse through the stderr string, there are some lines that aren't json! But again, not the hardest thing to deal with

[gregmarr]

You don't need an initializer here, it has a perfectly fine default constructor (see the line above).

[vanceism7]

Ah, for some reason I was thinking I needed to give explicitly give it a default value. Will fix, thanks!

[DyXel]

Why not just { "errors" : [ <your array of errors here> ]}? If this is meant to be ingested by another program, I don't think you even need to worry about newlines, dump the entire thing without superfluous white-spaces. If you really need to read it yourself, pipe to jq and call it a day. Just my 2 cents.

[vanceism7]

Why not just { "errors" : [ <your array of errors here> ]}? If this is meant to be ingested by another program, I don't think you even need to worry about newlines, dump the entire thing without superfluous white-spaces. If you really need to read it yourself, pipe to jq and call it a day. Just my 2 cents.

I'm not sure if I understand your suggestion. I mean, ideally I would rather have it structured as you mentioned, but it seemed simpler to me to modify the print function of error_entry itself; and adding the newlines makes it easier to call string.split in javascript, thats why I added the newlines in.
But to get access to all of the errors as an array, I have to go out to to_cpp1::print_errors and it felt like I was then gonna have to deal with a lot more manipulation of the logic around how errors are printed. The way you describe it makes it sound easier than what I did though, so it's possible I'm just missing something haha.

Mainly I was just trying to make the least invasive change I could to unblock the language server work

[vanceism7]

The more I'm thinking about this, the more I'm thinking this PR is the wrong approach. It solves the immediate problem of error reporting, but doesn't help solve any problems we'd run into later (when implementing a language server) like keeping track of identifiers and things of that sort. I notice there's a debug flag that outputs a couple of interesting files (parse, source, symbols, and tokens) - this is probably the more all-encompassing approach that needs to be done here. Some flag that can output a bunch of diagnostics information the compiler gathers (instead of just errors), and writes it out to json. This would be more generally useful I think.

Anyhow, I won't close this PR yet (in case it's decided we should keep the changes anyways), but maybe its better to scrap it and start again.
(Although I will admit, I think adding the symbol field to error_entry is possibly still a useful change to add in)

Edit:
Actually, I'm just gonna close this and try again. Thanks everyone for taking the time to review