'memoryview' was introduced in Python 2.7. 73ce96f78032 added code
to filterpyflakes.py to ignore "undefined name 'memoryview'" pyflakes
warnings. Since we no longer support <Python 2.7, we can remove this
workaround.
We've only got one kind of pyflakes failure left in our codebase, so
it's time to switch over to a blacklist-based checking scheme. I've
left in the filtering of two undefined names for now out of paranoia,
but those can probably go too.
Before this patch, 'filterpyflakes.py' reads target files relatively
to own location.
But this prevents third party tools from using it in own source tree,
because their files are placed separately from 'filterpyflakes.py'.
In fact, 'test-check-pyflakes.t', which is the only user of
'filterpyflakes.py', changes current working directory (cwd) to the
root of "test target" source tree before using it. Therefore,
composing the root of source tree in 'filterpyflakes.py' is redundant.
This patch makes 'filterpyflakes.py' read target files relatively to
cwd by invoking 'open()' without any path composition. This also
removes importing 'os' module, because there is no user of it after
this patch.
This is a one of preparation of issue4677.
Before this patch, "test-check-pyflakes.t" shows unexpected "undefined
name 'memoryview'" error for "mercurial/util.py" on Python 2.6.x or
earlier, because they don't define symbol 'memoryview'.
This patch introduces excluding patterns into "filterpyflakes.py" to
ignore "undefined name 'memoryview'" pyflakes error on Python 2.6.x or
earlier
It should be able to catch the following mistakes at 764c0874d3c8:
mercurial/exchange.py:590: undefined name 'UnknownPartError'
mercurial/match.py:346: undefined name 'pat'
mercurial/win32.py:365: undefined name '_ERROR_NO_MORE_FILES'
tests/killdaemons.py:46: undefined name 'check'
In filterpyflakes the term no-check-code was probably by accident.
In the test the intention was not to skip the entire file but only one
line. But any skipping seems to be unnecessary since a longer time.
The pyflake messages are simply ordered by message type, path, line no (and
message text).
The message type is taken from the order of the filters.
The previous ordering looks complicated and illogically.
It was the following order (r'\3:\5:\4:\1:\2:' + line):
message (\3 and \5)
var name (\4)
path (\1)
line no (\2)
line reference
Ordering by var name before path looks illogically for me.
