Static linking against glibc has crashes depending on the name
resolution setup (I think when it needs to dlopen). It is a fundamental glibc
limitation that we cannot fix on our end.
It will crash when doing `echo ~<TAB>`.
This carves out a specific exception for "gnu", i.e. glibc, targets.
Other targets, including musl and other operating systems, continue to
allow static linking.
The previous control flow logic wasn't sound and would leave the shell in a hung
state when `break` would be encountered.
The behavior is now straightforward, the shell reads until <Enter> or <q> is
pressed, at which point it aborts.
This was based on a misunderstanding.
On musl, 64-bit time_t on 32-bit architectures was introduced in version 1.2.0,
by introducing new symbols. The old symbols still exist, to allow programs compiled against older versions
to keep running on 1.2.0+, preserving ABI-compatibility. (see musl commit 38143339646a4ccce8afe298c34467767c899f51)
Programs compiled against 1.2.0+ will get the new symbols, and will therefore think time_t is 64-bit.
Unfortunately, rust's libc crate uses its own definition of these types, and does not check for musl version.
Currently, it includes the pre-1.2.0 32-bit type.
That means:
- If you run on a 32-bit system like i686
- ... and compile against a C-library other than libc
- ... and pass it a time_t-containing struct like timespec or stat
... you need to arrange for that library to be built against musl <1.2.0.
Or, as https://github.com/ericonr/rust-time64 says:
> Therefore, for "old" 32-bit targets (riscv32 is supposed to default to time64),
> any Rust code that interacts with C code built on musl after 1.2.0,
> using types based on time_t (arguably, the main ones are struct timespec and struct stat) in their interface,
> will be completely miscompiled.
However, while fish runs on i686 and compiles against pcre2, we do not pass pcre2 a time_t.
Our only uses of time_t are confined to interactions with libc, in which case with musl we would simply use the legacy ABI.
I have compiled an i686 fish against musl to confirm and can find no issue.
This reverts commit 55196ee2a0.
This reverts commit 4992f88966.
This reverts commit 46c8ba2c9f.
This reverts commit 3a9b4149da.
This reverts commit 5f9e9cbe74.
This reverts commit 338579b78c.
This reverts commit d19e5508d7.
This reverts commit b64045dc18.
Closes#10634
Add kqueue-based uvar notifier for BSD
Tested under FreeBSD 13.3.
This also works under all versions of macOS, and has some
benefits over the current notifyd choice.
Mutex is used because of the non-mut `notification_fd_became_readable()` `&self`
reference, but contention is not expected.
This restores a hack to trigger a command line repaint when "$fish_color_*" or
"$fish_pager_color_*" changes. These allow the command line to react immediately
to changes in other sessions or web_config.
This was removed in ff62d172e5 but there does not
appear to be a handler which actually redraws these.
Revert of ff62d172e5
The generated assembly is more or less the same and the previously generated
version had been manually verified, but this PR removes the usage of
`MaybeUninit::assume_init()` and replaces it with direct pointer writes.
This should result in no observable change: it continues to pass the functional
tests and benchmarks identically. The safety of the new code has been verified
with Miri.
[0]: https://github.com/mqudsi/fish-yaml-unescape-benchmark
- -q silenced warnings in apk 2.x but not in in 3.x, so redirect stderr
to /dev/null to avoid seeing warnings while completing (-q is still
passed to `apk search` as it strips package versions and releases)
- Drop `-q` from `apk info`, as on apk 3.x it prevents apk info from
outputting anything at all
I've tested these changes on both Chimera Linux (which uses apk 3.x)
and Alpine Linux (which is still using 2.x).
This does not work as-is ("CSI a" is shift-up, not up).
I'm not sure if we want to implement these.
It's not a regression so there is no pressure.
This reverts commit 350598cb99.
byte_to_symbol was broken because it didn't iterate by byte, it
iterated by rust-char, which is a codepoint.
So it failed for everything outside of ascii and, because of a
mistaken bound, ascii chars from 0x21 to 0x2F ("!" to "/" - all the punctuation).
char_to_symbol will print printable codepoints as-is and
others escaped. This is okay - something like `decoded from: +` or
`decoded from: ö` is entirely understandable, there is no need to tell
you that "ö" is \xc3\xb6.
This reverts commit 423e5f6c03.
This except clause was too narrow, so it would fail here even on other
systems just because webbrowser.get() returned nothing usable
Now it will fail *later* with "could not locate runnable browser", but
at least it won't say anything about chromeos on non-chromeos systems.
Array starts at 0, goes up to 27, that's 28 entries... *BUT* we also
need the catch-all entry after, so it's 29.
To be honest there's got to be a better way to write this.
WezTerm supports CSI u but unfortunately, typing single quote on a German
keyboard makes WezTerm send what gets decoded as `shift-'`.
This is bad, so disable it until this is fixed. In future we should maybe
add a runtime option to allow the user to override this decision.
See #10663
