GeezerVison

Description:

The old matcher only worked if the error was raised with raise Exception('single quotes').

This represents a miniscule fraction of errors; for instance, l[37] on a short list l can raise IndexError, and any call to a builtin C function is not going to trace back to a raise call.

Instead, this just matches the first line without fail that comes after the context line.

Note that this is still not foolproof; in Python 3.10, SyntaxErrors are produced as

  File "<stdin>", line 1
    foo(x, z for z in range(10), t, w)
           ^^^^^^^^^^^^^^^^^^^^
SyntaxError: Generator expression must be parenthesized

This matcher will incorrectly pick up ^^^^^^^^^^^^^^^^^^^^ as the error message, but the previous behavior was to not pick up any error message at all.

As far as I can tell, this is impossible to handle correctly; the grammar of problem matchers is far too limiting.

Some other changes:

• Remove nonsensical double-escaping of ". " is not a regex character, it needs only to be escaped once for JSON
• Require the traceback to appear in the first column, as this is how python usually handles it. There is no way to track indentation between lines, but we are forced to make a choice between catching errors not caused by raise (common) and catching errors which are printed by a custom handler (uncommon).

Related issue:
This follows on from

• Problem matchers #4

Check list:

• Mark if documentation changes are required.
• Mark if tests were added or updated to cover the changes.
  There are no existing tests for this feature, nor do I know if it is even possible to test.
  However, I tested this matcher in another action at https://github.com/sigproc-classrooms/sf2_competition_template/runs/6746359679?check_suite_focus=true#step:6:38, where you can see that it has correctly found an error that would not have previously matched.