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.
I just noticed that depending on the state of your working tree there can be
one or more spaces after the modification token and the file name. If there is
more than one space that causes the `string split` to produce unexpected
output.
In keeping with the change made by @ridiculousfish earlier today modify
the `keyword_description()` function to return a const wchar_t pointer.
Also, simplify the `token_type_description()` function to use the recently
introduced mapping array. This changes the wording of many of the token
type descriptions. However, I can't see this as being a problem since
the original descriptions (e.g., "token_redirection") are no clearer to
someone not acquainted with the implementation.
Fish keywords can be quoted and split across lines. Prior to this change
`fish_indent` would retain such odd, obfuscated, formatting. This change
results in all keywords being converted to their canonical form.
This required fixing a bug: the keyword member of parse_node_t wasn't being
populated. This hadn't been noticed prior to now because it wasn't used.
Fixes#2921
This code represents only risk and does nothing useful for anything
that can compile fish.
In C++ situations where __STDC_VERSION__ is unset (as it should be),
fish was assuming we are on < C99 and setting it to __FUNCTION__.
Basically always, __PRETTY_FUNCTION__ ends up reaplaced by __FUNCTION__, this hurt
error message usefulness and richness.
__PRETTY_FUNCTION__: const thing::sub(int)
__FUNCTION__: sub
