4f0ade7a73 broke the tests when LANG was
C, so the MB_CUR_MAX==1 path wasn't working.
Seemingly that cast is doing some work here?
Just revert that bit for now, since this path is unimportant
anyway (please, please, please, please use a unicode capable locale).
This is a reimplementation of the "vectorized" ASCII detection
from str2wcs_internal. This handles the case where only part of
a string is ASCII. It also avoids pointer overflow issues and improves
commenting.
Prior to this change, str2wcs_internal had an optimization for ASCII
inputs. However the main cost was the repeated bounds checks when
performing push_back() on the resulting wcstring.
Switch to determining the number of ASCII characters, and then appending
those all in one go. This improves the time in the 'convert_ascii' test
from ~450 usec to ~75 usec.
Found with gcc's -Wmissing-declarations which gives warnings like
../src/tinyexpr.cpp:61:5: warning: no previous declaration for ‘int get_arity(int)’ [-Wmissing-declarations]
61 | int get_arity(const int type) {
The same warnings show up for builtin functions like builtin_bg because they
currently don't include their own headers. I left that.
Also reformat the touched files.
This avoids the heavy hit of __gconv_transform_utf8_internal.
In the worst case, after `is_ascii` returns the string is guaranteed to
be in the CPU cache (assuming realistic input sizes). In the best (and
hopefully extremely common) case, the conversion table lookups are
completely avoided.
In terms of real world gains, simply calling `history` is anywhere from
2x to 3x faster for large history files composed of mostly ascii
content under glibc 2.31 on AMD64.
In commit fd6d814ea4, read_blocked was changed to read until EOF
or the full amount requested is returned. Switch this to returning
as soon as any data is available, which was the behavior prior to
fd6d814ea4.
This will allow builtin_string to output data in a "streaming"
fashion instead of needing to read a large block up-front.
This is like wcs2string, but instead of returning a std::string, it invokes
a user-supplied function with each converted character.
The idea is to allow interleaved conversion and output.
This makes it possible to expand the signals checked by the type. I can't merge
the sigttin fixes for #7060 yet because they introduce new breakage, but this
will make merging any future fix easier.
Finish the transition to termsize.h. Remove the scary termsize bits
from common.cpp, which can throw off events at arbitrary calls and are
dangerously reentrant. Migrate everyone to the new termsize.h.
Prior to this fix, fish would attempt to resize the terminal via
TIOCSWINSZ, which was added as part of #3740. In practice this probably
never did anything useful since generally only the tty master can use
this. Remove the support and note it in the changelog.
When fish exits, it tries to restore the foreground process group.
However this may actually steal control of the fg process group
from another process. Fix this by clearing the SIGTTOU handler so
that tcsetpgrp() will fail.
Credit to @mqudsi for awesome debugging.
Fixes#7060
I kinda hate how fussy clang-format is. It reflows text
constantly (line limit), forces things onto one line *except* when
they're too long, and wants to turn this:
```c++
return true;;
```
into this:
```c++
return true;
;
```
instead of, you know, eliminating the second semicolon?
Anyway, it is what it is and we use it, I'll just look into getting some
more slack.
This makes two changes:
1. Remove the 'brace_text_start' idea. The idea of 'brace_text_start' was
to prevent emitting `BRACE_SPACE` at the beginning or end of an item. But
we later strip these off anyways, so there is no apparent benefit. If we
are not doing brace expansion, this prevented emitting whitespace at the
beginning or end of an item, leading to #6564.
2. When performing brace expansion, only stomp the space character with
`BRACE_SPACE`; do not stomp newlines and tabs. This is because the fix in
came from a newline or tab literal, then we would have effectively
replaced a newline or tab with a space, so this is important for #6564 as
well. Moreover, it is not easy to place a literal newline or tab inside a
brace expansion, and users who do probably do not mean for it to be
stripped, so I believe this is a good change in general.
Fixes#6564
