Handle SyntaxErrors in a slightly smarter way
SyntaxErrors are strange and mystical beasts. On top of the problems we
encountered previously in GitLab#237, it's now apparent that
SyntaxErrors can also occur across multiple lines (in fact, across the
rest of a file). In the event of a "multi-line" SyntaxError, we need to
determine what row to report and what the column number is.
For now, we're going to use the row number of the first line and limit
the column number to be less than the end of the line. It may not be
perfect, but it is slightly better.
Related-to #237Closes#259
cc @arcanemagus
See merge request !151
By default, when discovering files for users, we use the filename
patterns to determine whether or not we should check that file. However,
when a user provides the path to a file, we should instead skip checking
the name against the filename patterns provided.
For example, in Flake8 2.6 this worked:
$ flake8 bin/script.py
$ flake8 bin/script
But prior to this commit only
$ flake8 bin/script.py
works. This commit will skip the filename pattern check if the user
provides the path explicitly which allows
$ flake8 bin/script
to work again as expected.
Closes#266
SyntaxErrors are strange and mystical beasts. On top of the problems we
encountered previously in GitLab#237, it's now apparent that
SyntaxErrors can also occur across multiple lines (in fact, across the
rest of a file). In the event of a "multi-line" SyntaxError, we need to
determine what row to report and what the column number is.
For now, we're going to use the row number of the first line and limit
the column number to be less than the end of the line. It may not be
perfect, but it is slightly better.
Related-to #237Closes#259
When we refactored our decision process to fix#239, we broke a subtle
corner case where extensions that are not off-by-default are to be
reported.
This further refactors that logic and adds specific tests around it to
ensure it works as expected and doesn't regress.
Closes#257
When running the git hook, even though the appropriate config file is
found and processed, the exclude patterns and paths were not being
corrected to account for the temporary directory that we copy the files
into.
Related-to #223
If we handle an exception, or early exit, or really anything, we should
exit non-zero (and we used to). This was a minor oversight.
Closes#209Closes#248
Do not print the source when provided with -q
When users specify any number of -q's on the command-line, we should not
show the source even if they have otherwwise configured Flake8 to do so.
Closes#245
See merge request !140
When users specify any number of -q's on the command-line, we should not
show the source even if they have otherwwise configured Flake8 to do so.
Closes#245
When we enable a plugin (when it's provided in the --enable-extensions)
plugin, we need to remove it both from the extended default ignore list
and the plain ignore list.
Closes#239
Change how we initialize our git hook application
Look for configuration files in the current directory while checking the
files in the temporary directory.
Closes#223Closes#210
See merge request !136
Previously, we didn't handle the case where an error code was implicitly
ignored (by not being in --select) and implicitly selected (by not being
in --ignore). This means we need to update StyleGuide#_decision_for and
StyleGuide#is_user_selected to handle these cases.
Closes#242
Related-to #239
Related-to !132
Add --tee option to split report output stream.
The `--tee` option allows the linter report to be written to stdout, even
though it is being redirected to a file with the` --output-file` option.
This is useful if I want to store the report in a separate file for later
analysis but also be able to print the output on screen (e.g when running
in a CI environment).
See merge request !90
We opted to not copy the file_tokens attribute each time it's accessed
in the merge request discussion but it was never reflected in the code.
Further, the attribute had no documentation or docstring, so we've added
that. Finally, we address a personal style nit that I otherwise wouldn't
have picked at.
In some cases, when we handle SyntaxErrors we need to ensure that the
column number is correct for a 1-indexed report. In some cases, we also
need to account for the fact that the SyntaxError has happened "after" a
new-line. To extract and alter the row and column numbers, we've moved
the logic to a private static method on the FileChecker object to avoid
an overly complex method.
Closes#237
When a SyntaxError is raised, column_number may be None. Unfortunately,
it's not obvious where that None comes from so we must handle it in
handle_error.
Closes#214
Add --bug-report flag to help bug reporters
When invoked it will print out JSON that has all of the debugging
information needed by the maintainers to diagnose or reproduce a bug.
Closes#207
See merge request !117
Serialize Checkers PluginTypeManager to a dict
*Description of changes*
Try to side-step issues with attributes not being set/updated on plugins when used with multiprocessing and Queues.
*Related to:* #179, #164
See merge request !98
It seems likely that the multiprocessing module on Windows is not
capable of serializing an object with the structure that we have and
preserving the attributes we dynamically set on plugins (like the
FlakesChecker). To avoid issues like this with all plugins (although
we have only found this on Windows with the FlakesChecker), let's try
serializing the Checkers PluginTypeManager to a dictionary so that the
only object that a Queue is really trying to serialize/deserialize is
the FlakesChecker itself.
Related to #179
Previously, all testing was done from the directory in which the
configuration file lived, so this bug went unnoticed. However, if you
run Flake8 against its own source from a directory above, you would
notice that the patterns in the exclude config value in tox.ini were
ignored. This is because we (like any reasonable person) are using
relative paths. The path is relative, however, to the directory in
which the configuration file was located. So we keep track of which
directory that is and use that to normalize the paths in the config
file.
Yes, there is an unrelated change to our tox.ini in this commit as
well. ;-)
Closes#194
