libafl_bolts tuples relies on standard library implementation details

[Noratrieb]

LibAFL/libafl_bolts/src/tuples.rs

Lines 27 to 58 in 89cff63

	/// Returns if the type `T` is equal to `U`, ignoring lifetimes.
	#[inline] // this entire call gets optimized away :)
	#[must_use]
	pub fn type_eq<T: ?Sized, U: ?Sized>() -> bool {
	// decider struct: hold a cell (which we will update if the types are unequal) and some
	// phantom data using a function pointer to allow for Copy to be implemented
	struct W<'a, T: ?Sized, U: ?Sized>(&'a Cell<bool>, PhantomData<fn() -> (&'a T, &'a U)>);
	// default implementation: if the types are unequal, we will use the clone implementation
	impl<T: ?Sized, U: ?Sized> Clone for W<'_, T, U> {
	#[inline]
	fn clone(&self) -> Self {
	// indicate that the types are unequal
	// unfortunately, use of interior mutability (Cell) makes this not const-compatible
	// not really possible to get around at this time
	self.0.set(false);
	W(self.0, self.1)
	}
	}
	// specialized implementation: Copy is only implemented if the types are the same
	#[allow(clippy::mismatching_type_param_order)]
	impl<T: ?Sized> Copy for W<'_, T, T> {}
	let detected = Cell::new(true);
	// [].clone() is *specialized* in core.
	// Types which implement copy will have their copy implementations used, falling back to clone.
	// If the types are the same, then our clone implementation (which sets our Cell to false)
	// will never be called, meaning that our Cell's content remains true.
	let res = [W::<T, U>(&detected, PhantomData)].clone();
	res[0].0.get()
	}

this code here relies on the (unsound) specialization of Copy for cloning of arrays. I hope I don't have to explain why that's a problem^^. this will probably break in the future (since it's unsound), either with the specialization being removed, the lifetime-dependent Copy implementation being an error or both.

how else should it be implemented then? not. this operation cannot be implemented correctly and a different way to do the stuff that uses it today needs to be found.

[domenukk]

Feel free to propose a better / sound way. I sadly don't know of any.

FWIW we do run tests in CI and would catch future breakage:

LibAFL/libafl_bolts/src/tuples.rs

Line 890 in 89cff63

fn test_type_eq() {

I agree it's not a good solution, but it'll be pretty hard to come up with a better one..

[Noratrieb]

There is indeed not really a better way. As I said, this is not an operation that can be implemented correctly. I recommend just deleting the functions. This repo doesn't seem to use it, and users of the crate need to find a different way.

[domenukk]

It's used here:

LibAFL/libafl_bolts/src/tuples.rs

Lines 495 to 501 in 89cff63

	fn match_name<T>(&self, name: &str) -> Option<&T> {
	if type_eq::<Head, T>() && name == self.0.name() {
	unsafe { (addr_of!(self.0) as *const T).as_ref() }
	} else {
	self.1.match_name::<T>(name)
	}
	}

And that's a pretty important piece, if we just leave it out we can run into type confusions everywhere..

I don't think there is much we can do until/if ever min_specialization lands, sadly..

[workingjubilee]

Then we can remove this from the standard library, and your code that has renounced stability guarantees by deliberately bypassing them will fail to compile.