When we changed our default from RelWithDebInfo to Debug, we inadvertently ended
up with all CI building and running in Debug mode. Change at least one of them
back to Release to make sure we don't have any optimizations that cause funky
stuff.
I'm changing the Ubuntu CI image because it's hopefully the fastest (since rust
is relatively dog-slow to compile in release mode).
This automatically assigns the 'completions' label and the 'fish next-3.x'
milestone to completions-only PRs.
A completions-only PR is defined as being one that touches
share/completions/*.fish but does not touch any files outside of share/
CARGO_NET_GIT_FETCH_WITH_CLI uses the `git` executable instead of the rust
git2 crate/lib, which speeds things up and is known to resolve some issues
fetching the registry or individual crates.
This is to work around a specific issue with git-resident Cargo.toml
dependencies (e.g. terminfo) that keep randomly failing to download under macOS
CI.
It appears we can't find a system that ships rustc >= 1.67 and < 1.70,
so keeping it at 1.67 gains nothing.
1.70 is used in Debian 13, so that will be able to build fish out of
the box (12 was on 1.63 which was already too low).
These are dog-slow at building, and the tests themselves are barely
sped up running as release.
Given that we have ~10 minute build and ~3 minute test time on Github
Actions on macOS, let's see if this speeds it up
(we can also do it for the others, but the most important is the
slowest test because that's what stops the checkmark appearing)
This was pretty annoying on rust release day, because it introduced
new warnings.
Specifically 1.73 introduced a spurious one about PartialOrd and Ord
disagreeing when both were in fact #derive-d.
- https://github.com/ATiltedTree/setup-rust has not been committed to since May
2022, I am uncertain about how widely used it is.
- It appears to have a bug with restoring its internal cache whenever there
comes a new stable version (immediate guess would be the cache-key does not
resolve `stable` to a specific version, which somehow breaks rustup, but I have not investigated)
- https://github.com/dtolnay/rust-toolchain is a more sensible take of https://github.com/actions-rs/toolchain,
where the original repo appears to be unmaintained.
It is implemented in one file of yaml/bash
https://github.com/dtolnay/rust-toolchain/blob/master/action.yml, we could
easily fork it if it becomes unmainted, unlike the other actions which uses
unnecessary javascript
Suppress TLS variable leaks caused by outstanding background threads by
suppressing the ASAN interposer functions. This is possible because because
we're now using use_tls=1.
-----------------------
Direct leak of 64 byte(s) in 2 object(s) allocated from:
#0 0x5627a1f0cc86 in __interceptor_realloc (/home/runner/work/fish-shell/fish-shell/build/fish_tests+0xb9fc86) (BuildId: da87d16730727369ad5fa46052d10337d6941fa9)
#1 0x7f04d8800f79 in pthread_getattr_np (/lib/x86_64-linux-gnu/libc.so.6+0x95f79) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
#2 0x5627a1f2f664 in __sanitizer::GetThreadStackTopAndBottom(bool, unsigned long*, unsigned long*) (/home/runner/work/fish-shell/fish-shell/build/fish_tests+0xbc2664) (BuildId: da87d16730727369ad5fa46052d10337d6941fa9)
#3 0x5627a1f2fb83 in __sanitizer::GetThreadStackAndTls(bool, unsigned long*, unsigned long*, unsigned long*, unsigned long*) (/home/runner/work/fish-shell/fish-shell/build/fish_tests+0xbc2b83) (BuildId: da87d16730727369ad5fa46052d10337d6941fa9)
#4 0x5627a1f19a0d in __asan::AsanThread::SetThreadStackAndTls(__asan::AsanThread::InitOptions const*) (/home/runner/work/fish-shell/fish-shell/build/fish_tests+0xbaca0d) (BuildId: da87d16730727369ad5fa46052d10337d6941fa9)
#5 0x5627a1f19615 in __asan::AsanThread::Init(__asan::AsanThread::InitOptions const*) (/home/runner/work/fish-shell/fish-shell/build/fish_tests+0xbac615) (BuildId: da87d16730727369ad5fa46052d10337d6941fa9)
#6 0x5627a1f19b01 in __asan::AsanThread::ThreadStart(unsigned long long) (/home/runner/work/fish-shell/fish-shell/build/fish_tests+0xbacb01) (BuildId: da87d16730727369ad5fa46052d10337d6941fa9)
#7 0x7f04d87ffb42 (/lib/x86_64-linux-gnu/libc.so.6+0x94b42) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
#8 0x7f04d88919ff (/lib/x86_64-linux-gnu/libc.so.6+0x1269ff) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
Set use_tls back to its default of 1.
This is required to work around an ASAN/LSAN virtualization bug but seems to be
behind the random __cxa_thread_atexit_impl() leaks?
Rust has multiple sanitizers available (with llvm integration).
-Zsanitizer=address catches the most likely culprits but we may want to set up a
separate job w/ -Zsanitizer=memory to catch uninitialized reads.
It might be necessary to execute `cargo build` as `cargo build -Zbuild-std` to
get full coverage.
When we're linking against the hybrid C++ codebase, the sanitizer library is
injected into the binary by also include `-fsanitize=address` in CXXFLAGS - we
do *not* want to manually opt-into `-lasan`. We also need to manually specify
the desired target triple as a CMake variable and then explicitly pass it to all
`cargo` invocations if building with ASAN.
Corrosion has been patched to make sure it follows these rules.
The `cargo-test` target is failing to link under ASAN. For some reason it has
autocxx/ffi dependencies even though only rust-native, ffi-free code should be
tested (and one would think the situation wouldn't change depending on the
presence of the sanitizer flag). It's been disabled under ASAN for now.
