The `python` command may not exist on a system with Python 3 installed.
See https://peps.python.org/pep-0394/ for a discussion of the commands
expected to be installed.
Since Python2 was officially sunsetted almost three years ago
(https://www.python.org/doc/sunset-python-2/), IWYU should prefer
compatibility with newer systems over older ones.
Python code in scripts is still Python3/Python2-compatible, but we will no
longer make an effort to preserve Python2 support over time.
Fixes#1096.
Apart from being easier to read by humans, this improves the cooperation
with other tools (e.g. Jenkins' warnings-ng plugin, various Emacs modes)
quite a bit. As an example, here the previous output:
Foo.h:1:1: error: add the following line
class Bar;
Foo.h:18:1: error: remove the following line
#include "Bar.h"
Foo.cc:1:1: error: add the following line
#include "Baz.h" // for Huey, Dewey, Louie (ptr only)
Foo.cc:19:1: error: remove the following line
#include "Blah.h"
With this patch:
Foo.h:1:1: error: add 'class Bar;'
Foo.h:18:1: error: superfluous '#include "Bar.h"'
Foo.cc:1:1: error: add '#include "Baz.h"' (for Huey, Dewey, Louie (ptr only))
Foo.cc:19:1: error: superfluous '#include "Blah.h"'
If a compiler wrapper like ccache is used in the compile command
database, then iwyu_tool will only replace the wrapper with
IWYU_EXECUTABLE, while keeping the compiler executable in the
compile_args list. This leads to "error: no such file or directory
'c++'" warnings.
Fixes#789.
If the entry looks like this:
{
"arguments": [
....
],
"directory": "/path/to/test",
"file": "Test.cpp"
},
And we invoked iwyu_tool.py in /path/to, then the constructed abs path was
/path/to/Test.cpp, not /path/to/test/Test.cpp, fix this.
This is a breaking change.
Originally, the extra arguments after '--' were only intended for IWYU
args, and so '-Xiwyu' was automatically prepended to each of them to
make life easier on users.
But this made it impossible to add additional Clang args, which is also
a useful feature.
The extra arguments are now forwarded as-written to main and users need
to manually add '-Xiwyu' before every IWYU argument.
shlex.split does not do the right thing on Windows, not even with the
posix=False flag set.
Work around this with a hand-built win_split function, based on the
more or less official specification:
https://docs.microsoft.com/en-us/previous-versions/17w5ykft(v=vs.140)
Add tests.
No behavior change for non-Windows systems.
Fixes#583.
Match cl.exe without case on Windows to allow for e.g. CL.EXE.
Also match 'clang-cl', which could presumably be used as a cross-tool on
non-Windows systems.
Add tests.
User-provided paths are now matched case-insensitively.
Also fix a bug where /a/b/partial would match partial filenames. The new
implementation is stricter and only matches proper directory prefixes or
the full path name.
Closes bug #582.
- Two blank lines between module-level entities.
- Imports after doc comment
- Naming in execute
- Collapse IWYUToolTestBase into IWYUToolTests
No functional change.
If iwyu_tool.py is call by a relative path, include-what-you-use will
also be called with a static, relative path. Which breaks once the
cwd changes. So force the tool path to be absolute.
Python's multiprocessing module is convenient for task parallelization,
but it is rather weak when it comes to error reporting and handling
KeyboardInterrupt. It was basically impossible to interrupt iwyu_tool
with Ctrl+C.
Also, it seems silly to launch a process just to launch a process --
iwyu_tool.py basically just manages include-what-you-use child
processes.
Remove the use of multiprocessing and handle process scheduling
ourselves.
- Add execute function to run all invocations (asynchronously)
- Move process invocation to Invocation.run
- Make Invocation.from_compile_command a class method to make it easier
to stub Invocation.run when under test.
With this in place, add basic test cases for compile command parsing and
execution.
The new Invocation class knows how to parse a compilation database entry
and expose an IWYU command and a cwd.
This simplifies the main flow a little; all compilation database entries
are transformed to Invocations up-front, and then the pool can just work
away at process invocations.
No functional change.
- Add new function slice_compilation_db that returns a reduced
compilation database tailored for the provided source files.
- Warn if path in selection does not exist on disk
- Warn if path in selection does not exist in compilation database
This also fixes a bug where iwyu_tool.py would say a file did not exist
in compilation database, when in fact it didn't exist on disk.
- Don't use shell=True, instead use different executable names for
Windows/Unix
- Use shlex.split to parse 'command' entry of compilation
database. Should handle arguments with spaces correctly.
- Maintain the compile command as a list throughout, instead of dumbing
down to a space-separated string
- Move -Xiwyu-prefixing to command-line parsing
- In verbose mode, print include-what-you-use command-line with a '# '
prefix instead of trailing colon.
No functional change intended.
Avoid that iwyu_tool.py relies on finding include-what-you-use from the
PATH, i.e. even if iwyu_tool.py is not in the path and gets executed by
absolute path, it should still succeed in finding the executable binary
include-what-you-use.
Move things around a little to make this easier to implement -- run_iwyu
now translates from a compilation database entry to a command-line.
This should fix issue #456.
Use Python's multiprocessing to run source files in parallel. Default number of
jobs is 1, so no functional change by default.
Minor bug (missing comma in argument parser) fixed and squashed by Kim
Grasman. This is the equivalent of PR #444.
The standard output format of iwyu is not very friendly for tools like
Jenkins' warnings-plugin (https://github.com/jenkinsci/warnings-plugin) or
editors. This change adds a new -o/--output-format command line option with
'iwyu' being the traditional format and 'clang' the new one for mangling the
output into something clang-like, enabling nice integration into
emacs/Jenkins/etc. out of the box.
Somehow this should probably be the default and be handled on the native
side (not as a post-processing step), but the current change is probably the
least controversial and easiest one for now.
When use realpath on source files given on the command line, so we should
better use realpath for the paths in the compilation DB, too. Otherwise we
don't find source paths which contain a symbolic link and incorrectly emit a
warning instead.
This should fix/work around issues #87 and #164.
Ideally IWYU should support compilation databases natively, but the Clang
Tooling infrastructure doesn't fit cleanly into IWYU's model, so we'll
start with this as a workable compromise.
Based on initial patches by Ryan Pavlik and showard314, thanks!
Seth R. Johnson