--filename-in-msg updates wording of runtime exceptions, too

[WardBrian]

Closes #1333

Submission Checklist

• [x] Run unit tests
• Documentation
  • [ ] If a user-facing facing change was made, the documentation PR is here:
  • [x] OR, no user-facing changes were made

Release notes

--filename-in-msg now also affects the name of the file shown in runtime exceptions. Useful for interfaces which use mangled or temporary names during compilation.

Copyright and Licensing

By submitting this pull request, the copyright holder is agreeing to license the submitted work under the BSD 3-clause license (https://opensource.org/licenses/BSD-3-Clause)

[nhuurre]

Weird corner case:

// example.stan
model {
  vector[1
  #include part.stan
}

// part.stan
-2] x;

generates an error message that displays the original file name

(in 'newname.stan', line 3, column 9 to './part.stan', line 2, column 2, included from
'example.stan', line 4, column 2)

The fix is easy enough, add ?printed_filename to line 17 in Location_span.ml, or alternatively (perhaps more consistently) skip the end_loc_str entirely if end_loc.included_from is not None (equivalent: end_loc.filename does not equal begin_loc.filename).

[WardBrian]

Huh. The compiler definitely doesn't like when #includes contain less than a full statement, and can cause weird behavior. Luckily this isn't a common occurence, but I did put together some examples a while back of technically valid programs which crash the pretty printer: https://github.com/WardBrian/stanc3/tree/tests/failing-pretty-printer/test/integration/bad/includes

The example you provide there is another that crashes when you use --auto-format without --canonicalize=includes. These deserve a better look one day, but I think your proposed solution to the problem in this PR is a good one.