Drop cxx-stl

[axd1x8a]

No description provided.

[axd1x8a]

Requires #259 to be merged first

[vswarte]

@nex3 can you confirm this works for DS3 too as far as you can?

[nex3]

This is (and has always been) unsound. The From implementation especially allows you to convert from a pointer which provides no guarantees that the allocator is even initialized, let alone that it will live as long as as the reference. We should take this opportunity to fix it.

The most straightforward solution would be to just use &'static DLAllocatorBase instead for the vast majority of uses that do in fact refer to global allocators that last the entire process lifetime. That means we don't have to invent a bunch of our own custom infrastructure around creating and using it; we can just implement fromsoftware_shared_stl::Allocator for DLAllocatorBase directly.

If/when we need to model weirder situations like arena allocators that only exist for the lifetime of some parent object, we could use a newtype specifically for that like ShortLivedDLAllocator. This would also implement fromsoftware_shared_stl::Allocator to DLAllocatorBase, but it would have to strictly require (in the "Safety" block) that any ShortLivedDLAllocator members on FFI structs be private; otherwise, a caller with a mutable reference could potentially take ownership of it and use it beyond its stated lifetime without an unsafe {} block. This would have to include the STL types.

[axd1x8a]

The problem here is: allocator type in collections is actually pointer to an allocator, so implementing it for DLAllocatorBase will not work, and we can't implement anything for NonNull or use OwnedPtr to get Deref.

[nex3]

Thinking about this more, I think we have to make this &self, not &mut self. Most allocators in these games are thread-safe, and for those it's expected that de/allocation calls be made concurrently across multiple threads. If this is &mut self that means that self can change while we hold a mutable reference, which violates soundness.

For arena allocators, we can treat them as having implicit UnsafeCells.

[nex3]

This should also return &'static DLAllocatorBase.

[nex3]

I don't think we should tie the allocator infrastructure so tightly to STL in particular. The same DLKR allocators are used all over the codebase, not just in STL types. Particularly with #269, we'll want to call the allocation and deallocation functions in contexts that are divorced from STL.

In practice, I think this means that we shouldn't rename DLAllocatorReference to DLAllocatorForStl. We can still use fromsoftware_shared_stl::Allocator to represent the user-friendly allocation interface, though.