build(deps): update allocator-api2 to 0.4

[mkroening]

No description provided.

[phip1611]

why don't you use dependabot for this?

[mkroening]

why don't you use dependabot for this?

Because I want to avoid the noise from updating Cargo.lock a lot. Updating dependencies in Cargo.toml is often worth a thought to me.

For example, I think that this PR is breaking since users need to use the right allocator-api2 version, but cargo-semver-checks cannot check cross-crate items yet.

#17 on the other hand, should not be breaking, since no items from other crates are involved for users.

[phip1611]

Because I want to avoid the noise from updating Cargo.lock a lot.

Are you worried about all the PRs you have to merge? It is fairly easy to configure dependabot to automerge everything. I use it in all my repos. 🤔 breaking changes weren't an issue for me so far (luckily)

[mkroening]

Are you worried about all the PRs you have to merge? It is fairly easy to configure dependabot to automerge everything. I use it in all my repos. 🤔 breaking changes weren't an issue for me so far (luckily)

Not really; I think it just feels tidier for me personally if a library does not have a libc bump in the Cargo.lock every week, which makes the history less easy to scroll around in. Of course, one could reduce the frequency, but I think I generally prefer running cargo update before a release.

I have considered automating merges, but reading through the updates is interesting to me most of the time and reveals new possibilities to adapt to.

[phip1611]

is there a reason to support the allocator-api? I know it is a downstream crate. But at least the upstream effort is dead. I also removed the allocator-api of all my crates for that reason

(I suppose allocator-api2 wants to stay close to the rustlang feature)

[mkroening]

The upstream design has not changed a lot and will not be stabilized, yes, but there is nothing else to use, is there?

I think it makes sense for virtq::Used and virtq::Avail to be allocatable from something apart from the #[global_allocator], since these types are used for device communication. On nightly, we can use the never-to-be-stabilized allocator API. I can personally live with the nightly support, but it feels lacking not to give any possibility to allocate these types on a non-global allocator on stable, even though the allocation API has no future in its current form.

[phip1611]

I see. A shame that they didn't build something like the allocator_api right from the beginning