Now that the IWYU cleanup has been merged compile all, not just a couple, of
the builtin modules independent of builtin.cpp. That is, no longer `#include
builtin_NAME.cpp` in builtin.cpp. This is more consistent, more in line with
what developers expect, and is likely to reduce mistakes.
Reduces lint errors from 384 to 336 (-13%). Line count from 6307 to 4988 (-21%).
Another step in resolving issue #2902.
- Set PCRE2_SUBSTITUTE_OVERFLOW_LENGTH to get the required buffer length
from pcre2 instead of guessing
- Set PCRE2_SUBSTITUTE_EXTENDED to enable extra goodies in the
replacement string
Remove the "make iwyu" build target. Move the functionality into the
recently introduced lint.fish script. Fix a lot, but not all, of the
include-what-you-use errors. Specifically, it fixes all of the IWYU errors
on my OS X server but only removes some of them on my Ubuntu 14.04 server.
Fixes#2957
This ensures they can just be called and "the right thing" will happen -
fish_user_key_bindings will be executed, the variable will reflect the bindings.
This makes fish_mode_prompt rely on $fish_key_bindings instead.
fish_bind_mode is also set in default mode (only always "default"), so
it can't be used as the indicator.
I noticed that Doxygen was also complaining about the "<asis>" and "<bs>"
tags. So convert those to the backslash form like we did for "<outp>" in the
previous commit.
Doxygen has been warning that `<outp>` and `</outp>` are not valid XML/HTML commands since commit cb6d5d76 on 20016-04-04. That's primarily because there is at present no way to tell Doxygen to recognize new XML/HTML tags. The actual errors look like this:
```
.../string.doxygen:187: warning: Unsupported xml/html tag </outp> found
```
I hate build errors since they a) cause needless concern, and b) make it harder to notice when I've introduced a new error. So switch from XML/C## style markup to Doxygen style markup for the "outp" annotation.
The OS X Xcode IDE has a weird requirement that block comments preceding a
function or class definition must begin with three slashes rather than two if
you want the comment displayed in the "Quick Help" window.
Make the history code conform to the new style guide. Every change was
produced by clang-format (e.g., `make style`) with the exception of
comments which were manually reformatted. That has to be done by hand
since clang-format leaves comments alone other than to reflow comment
lines to get them below the allowed line length.
The total number of lines is reduced by 313 lines (13%) in the two
affected files. Line count is generally a poor metric but in this
case it reflects an increase in information density without a loss in
readability. Furthermore, the standardization of braces, whitespace,
and comment style will make it easier for people to read the code.
This reduces the number of warnings by `make lint` from 168 to 87 (a 48%
decrease). Making it much easier to focus on the substantive lint issues.
Further improvements are possible. For example, many comments are not
very helpful (e.g., they point out the obvious) or provide insufficient
detail. But those are beyond the scope of this change.
This is the first step in resolving issue #2902.
The readlink() function does not null terminate the path it returns.
Remove the OS X code that deals with a path buffer that is too short. For
one thing a loop isn't needed since we're told how big of a buffer
is required if the first _NSGetExecutablePath() call fails. But more
important it is so unlikely that the path will be longer than PATH_MAX
that if it is we should just give up.
Fixes 2931.
(cherry picked from commit 8e103c231e)
If there are uncommitted changes use `git-clang-format` to limit the style
fixups to the lines being modified.
Refuse to do a `make style-all` if there are uncommitted changes.
Include a fix for the parsing of `git status` output that was recently
incorporated into the lint.fish script.
The readlink() function does not null terminate the path it returns.
Remove the OS X code that deals with a path buffer that is too short. For
one thing a loop isn't needed since we're told how big of a buffer
is required if the first _NSGetExecutablePath() call fails. But more
important it is so unlikely that the path will be longer than PATH_MAX
that if it is we should just give up.
Fixes 2931.
