The indenter did not handle these backslashes well, interpreting them as
unary operators, and they are an edge case anyway. Line continuations
in string literals and character constants are kept.
Remove the need to explicitly initialize the buffers. To avoid
subtracting null pointers or comparing them using '<', migrate the
buffers from the (start, end) form to the (start, len) form. This form
also avoids inconsistencies in whether 'buf.e == buf.s' or 'buf.s ==
buf.e' is used.
Make buffer.st const, to avoid accidental modification of the buffer's
content.
Replace '*buf.e++ = ch' with buf_add_char, to avoid having to keep track
how much unwritten space is left in the buffer. Remove all safety
margins, that is, no more unchecked access to buf.st[-1] or appending
using '*buf.e++'.
Fix line number counting in lex_word for words that contain line breaks.
No functional change.
A comment is not supposed to change the state of the 'blank line after
declaration', but it did. The initialization of saved_just_saw_decl was
wrong though since it tried to capture the previous value after it had
already been overwritten.
This fixes several bugs where blank lines were erroneously added or
removed, treating these old bugs for new bugs in different places.
These new bugs are expected to be easier to fix, as the old bugs will
not interfere anymore.
the pathname matching tests ... this is not used in any way in a normal
test run, but if there are problems, one needs a mechanism to discover
whether the issue is with the code that creates the directory tree in the
test, or with the matching (either what the test expects to happen, or
what the shell actually does). The couple of lines being fixed here make
that mechanism work --- I have had this in my private sources for years
now, but never got around to committing it. It is time. NFC for any
normal test run.
It is not the job of an indenter to swap tokens, even if it's only about
placing comments elsewhere. The code that swapped the tokens was
complicated, buggy and impossible to understand.
In -br (brace right) mode, indent no longer moves a '{' from the
beginning of a line to the end of the previous line, as that was handled
by the token swapping code as well. This change is unintended, but it
will be easier to re-add that now that the code is simpler.
Previously, the type was reported as 'int' instead of 'enum'.
Continue to only report the type simple for pointer types, as the exact
pointer type is irrelevant to this message.
Previously, lint accepted -X '1, 2, 3', while the manual page lists the
IDs without spaces.
On 32-bit platforms, lint accepted -X -4294967295, and on 64-bit
platforms, it accepted the corresponding larger numbers.
The code for parsing message IDs and query IDs conceptually does the
same, but the implementations differed for no reason.
New test case that reflects the fix in PR kern/57260. The majority of
work for this case itself was by riastradh@, who'd supplied the basis
for it in the ticket, and provided further guidance.
https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html
The previous attempt (message 351 about 'extern' declarations outside
headers) did not cover the proposal from the tech-userlevel mailing list
but instead warns about a different usage pattern of the 'extern'
keyword.
to the next instruction. Only ERESTART should return to
the same instruction. Differences to sparc64 reduced.
Test t_ptrace_wait:syscallemu1 now passes on sparc.
Fixes PR kern/52166 "syscallemu does not work on sparc (32-bit)"
Ok: Martin Husemann
to what the shell produces for tilde expansions, when the expansion
of the tilde prefix ends with '/' and the character immediately following
is another '/' - previously /bin/sh (and most other shells, but not all)
retained both slashes, and this test expected that behaviour.
No longer, now only one of the two will appear. Adjust the expected
test results accordingly, and add an extra loop iteration to make sure
this is thoroughly tested (one more tilde expansion value).
Also, add two new test cases that test for the new (explicit - though
it was always stated this way, but not as explicitly) that if HOME is
an empty string (not unset - that remains an unspecified case, as it
was) then the expansion of ~ must generate "", and not nothing.
The current test was unable to distinguish those two, since it
simply looked for characters in the output, so add a new test cases
explicitly to test for this particular case. This also means (also
previously in the standard, but not as explicitly) that shells are
not permitted to decide "The ~ expansion produces an empty string, that
is weird, let's generate something else instead" which some shells were
doing.
rillig