Closed workingjubilee closed 1 year ago
unsafe
code in pgx
, because a lot of the work that has been done to make our pointer abstractions better has been entirely recent. And by "recent", I mean "it was stabilized 6 months ago". While working to make pgx::datum::Array<'a, T>
safer, more correct, and eventually faster, I accidentally used a library feature stabilized in Rust 1.63[^1], to which I say: lmao.const fn
stabilization in Rust 1.63, that's https://github.com/tcdi/pgx/pull/833, which uses Mutex::new()
becoming stable in const fn
to avoid having to use a Lazy
(from another dependency! once_cell
) just to initialize with Mutex::new(Vec::new())
(which is just a Mutex
around a nullptr and two 0s).[^1]: Per the tracking issue for #![feature(slice_ptr_len)]
, it's almost impossible to get the len
of a pointer to a slice correctly without NonNull<[T]>::len()
so I didn't have many options here.
We are rapidly approaching (really, have passed already several times over) the point where it does not make sense to continue pinning a version, even for the convenience of anyone's security processes.
core::ffi::CStr
. It allows removing dependencies (core_cstr
), so it reduces the amount of code that anyone has to worry about in the supply chain, but by pinning to 1.61 we are losing that opportunity.std::thread::scope
. It allows removing a large dependency in the build system forpgx-pg-sys
, therayon
dependency which brings in about a dozen other crates, so it significantly reduces the amount of code that anyone has to worry about in the supply chain, but by pinning to 1.61 we are losing that opportunity.#[link_section]
is not independently detected asunsafe
until then, only#[no_mangle]
but that is, again, still an unsupported version in security terms, so realistically, moving from an unsupported version to an unsupported version is not really acceptable.cargo pgx
for the specific pinned rustc version. These pointless rebuilds slow down every single patch I might write for PL/Rust. It can easily consume an hour or more on pure faffing about when switching back and forth, partly assisted by sometimes forgetting and only hitting the secondary issues caused by not doing so, thus having to debug it, and only then remembering to rebuild and reinstall, etc. This is already a test suite that takes too long to run and debug, this makes it even more unconscionable.unsafe
detection upstream in rustc and submitting patches for what we find, and that would only come to stable ~2 versions after it merges.std::backtrace::Backtrace
. It's intended to be a key component of newer, more sophisticated and better-scoped error-handling in Rust. Even if it's mostly going to be a diagnostic improvement, it's a lot to not have.