nicovank
commented
1 year ago The main work to support a new language is parsing the error message to get filenames / line numbers so that the source can be read and transmitted. As of right now, this is happening with regular expressions to match filenames. https://github.com/plasma-umass/cwhy/blob/3cea72ea3b698d061fbe25fadd27761ea33588c0/src/cwhy/cwhy.py#L206-L207 https://github.com/plasma-umass/cwhy/blob/3cea72ea3b698d061fbe25fadd27761ea33588c0/src/cwhy/cwhy.py#L210-L211 https://github.com/plasma-umass/cwhy/blob/3cea72ea3b698d061fbe25fadd27761ea33588c0/src/cwhy/cwhy.py#L214-L215
One of the existing regexes may already be matching filenames in C# diagnostic messages. If not, the best way to add C# or another language as of right now:
- Have a couple sample minimal C# files generating error messages (they can live in
tests). - If filenames are not matched already, add a new regex in
explain_context. - Verify the regex works, but most importantly that it doesn't mess with existing things by matching additional parts of a C++ clang diagnostic for example. This is typically signalled by "file not found" warnings.
If we keep adding support for more languages maybe we should 1. have a per-language mode, attempt to auto-detect the language, and make it a CLI option 2. have more robust per-language filename matching (or get a machine parseable version if one exists?).
I'm not very familiar with C# personally, so I don't really have any sample code with common or less common error messages at hand.
emeryberger
how complicated will it be to add support for C#? or any other language for this matter (like GO)?
if I wanted to add those myself as a PR, what steps would I need to take?