This is the unadorned result of:
git grep -En "\w.*return .*;" -- ':!tests/*' | grep-format
Having return statements on their own line makes it easier to set
breakpoints in most debuggers.
No functional change.
As reported in issue #981, using std::regex in IWYU has caused a
tremendous performance regression for large mapping files containing
regex mappings.
$ cat t.cc
#include <string>
# with llvm::Regex
$ time include-what-you-use -Xiwyu --mapping_file=qt5_11.imp t.cc
...
real 0m0,529s
user 0m0,509s
sys 0m0,020s
# with std::regex
$ time include-what-you-use -Xiwyu --mapping_file=qt5_11.imp t.cc
...
real 0m29,870s
user 0m29,717s
sys 0m0,012s
qt5_11.imp contains 2300+ regex mappings, and <string> has a bunch of
includes, so this is a good testbed for regular expression engines, but
over 50x slower is not the result we were hoping for.
The reason we switched to std::regex was to get support for negative
lookaround (llvm::Regex does not have it), but exotic regexes in
mappings are pretty rare, and this is a significant performance hit.
Introduce a --regex option to select regex dialect, with documented
tradeoffs. Put the default back to LLVM's fast implementation.
This fixes issue #981.
Sometimes for debugging and testing, it helps to be able to tweak IWYU behavior
beyond the log verbosity.
Add a free-form --debug argument that takes a comma-separated list of flag
names. No validation is performed on these flags, they just serve as a global
switchboard to enable/disable custom behavior.
Note that these are not intended as a replacement for switches in general, just
as a support structure for quickly adding conditional debug behavior while
troubleshooting.
Two new options:
--error: sets the exit code to use if there are IWYU violations
--error_always: sets the exit code to use whether there are IWYU
violations or not
Add tests to capture all relevant combinations of
(no warnings, warnings) x
(--error, --error_always) x
(explicit arguments, default values)
and make sure --error_always overrides --error.
Exit with EXIT_FAILURE if the command-line arguments are invalid or
Clang fails to parse the input. Otherwise exit with EXIT_SUCCESS.
Add tests to capture this new policy.
Fixes#75 and fixes#494.
Add `--update_comments` option to make IWYU always print the 'why'
#include comments, regardless of whether any include lines need to be
added or removed. With this change, IWYU will update the "// for xyz"
comments as the code changes, preventing the comments from becoming
stale.
This opts in for the more concise syntax introduced in C++17: namespace
a::b { ... }.
Usage of this is especially useful in codebases where existing forward
declarations in nested namespaces already use this form: so the IWYU
suggestion for new forward declarations can be consistent with the
existing ones.
fix_includes.py already handled this, but add a test to maintain this
behavior, too.
- Remove DEVTOOLS_MAINTENANCE_ from header guards, that was a
now-unnecessary Googleism
- Fix header guard to match filename in all production code
- Fix header guard to match path in all tests
IWYU now supports a new --pch_in_code switch which indicates the first
include directive in the translation unit is a precompiled header.
Precompiled headers are treated as prefix headers, even though they
were not specified on the command-line, but they can never be removed.
Finally, they sort first in include lists generated by IWYU, because
most compilers require the PCH to be included before anything else.
--prefix_header_includes controls presence of includes and forward declarations
involving files included via command-line option -include. Issue is reported by
Max Dyckhoff.
--no_default_mappings will cause IWYU not to add the default GCC-oriented mappings, to make it easier to build custom mapping suites for other toolchains.
Search for mapping files:
- in the current working directory;
- in the directory where IWYU executable is located;
- in the directory where another discovered mapping file is located.
This was motivated by an attempt to understand how iwyu_ast_util.cc
depended on iwyu_output, which turned out to be the use of VERRS.
I split the VERRS definition out into a separate iwyu_verrs module.
In the fallout from this I discovered some circular dependencies
that this CL attempts to disentangle.
R=csilvers
DELTA=603 (349 added, 222 deleted, 32 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3892
directories as specified on the compiler line, when deciding
whether to use "" or <>. Hard-code in some rules for google3
where we don't do it quite right.
To fully fix the associated bug, I also noticed that our cfoo
<-> foo.h mappings was missing stddef.h, which is defined in a
different place from other headers. I added it in.
R=wan,dsturtevant
DELTA=161 (69 added, 20 deleted, 72 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1597
--transitive_includes_only mode (controlled by a flag). In
this mode, we will throw out suggestions that file a #include
file b if file b is not visible in file a's transitive
includes; that is, all we do is move indirect includes to
direct includes, we never add a 'totally new' include.
While it's certainly possible for a 'totally new' include
suggestion to be correct, in our experience it's much more
commonly an iwyu error, usually because iwyu associates a use
with the wrong file. We control this by a flag so the user
can decide themselves whether they care more about false
positives or false negatives.
R=dsturtevant
DELTA=132 (123 added, 2 deleted, 7 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1592
accessible 'commandlineflags' struct. This replaces the
rather ad-hoc collection of variables and functions, spread
across 3 different files, that we have now. The motivation is
adding a new commandline flag that I want to be visible in yet
a fourth file; I figured that was a good time to consolidate.
Now iwyu_globals holds everything.
R=wan,dsturtevant
DELTA=306 (161 added, 112 deleted, 33 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1591
test some main()-invariant logic while I'm at it.
DELTA=19 (16 added, 0 deleted, 3 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1409
thought I was saying the location is where the . (or ->) is,
which is what I want, but clang doesn't actually expose that.
So I have go through some hoops to try to figure it out.
We were actually seeing a problem with this when running:
blaze build --host_cpu=k8 --compile_only -k --crosstool_top=//third_party/llvm/crosstool --plugin=//devtools/maintenance/include_what_you_use:run_iwyu //gws/plugins/local/src:enhanced_listing_ad
It has 'msg_->MSG_foo' in it, where MSG_foo is a macro. We
were attributing this use to the file defining MSG_foo, rather
than to us. With this change, we properly attribute it to us.
R=dsturtevant
DELTA=150 (125 added, 6 deleted, 19 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1347
HasMapping before mappings were finalized. And indeed, the
glob mappings were being left out. I solve this by doing the
reexport-protection check after mappins are finalized, in the
preprocessor.
While in the area, I added a few include-picker mappings that
had been inadvertently omitted before, or discovered in
testing. In particular, glob defines its own size_t, which is
weird; we don't want to depend on glob for size_t.
R=dsturtevant
DELTA=141 (129 added, 2 deleted, 10 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=889
Kim Gräsman