Use a better python problem matcher

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, `SyntaxError`s 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.
This commit is contained in:
Eric Wieser 2022-06-07 18:21:56 +01:00 committed by GitHub
parent 53e15292cd
commit 82009b3bde
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

9
.github/python.json vendored
View file

@ -4,13 +4,16 @@
"owner": "python",
"pattern": [
{
"regexp": "^\\s*File\\s\\\"(.*)\\\",\\sline\\s(\\d+),\\sin\\s(.*)$",
"regexp": "^ File \"([^\"]*)\", line (\\d+).*",
"file": 1,
"line": 2
},
{
"regexp": "^\\s*raise\\s(.*)\\(\\'(.*)\\'\\)$",
"message": 2
"regexp": "^ .*$"
},
{
"regexp": "^(?! File)(.*)\\s*$",
"message": 1
}
]
}