Add no_std support

[CrazyboyQCD]

no_std support can be enabled by compiling with --no-default-features to disable std support and --features hashbrown for Hash collections that are only defined in std for internal usages in crate. For example:

[dependencies]
gpu-allocator = { version = "0.27.0", default-features = false, features = ["hashbrown", "other features"] }

[MarijnS95]

Nice to see gpu-allocator usable on no_std with relatively minor changes! Thanks for doing the setup work here.

Just not sure if we're happy to commit to this rather tricky list of mutually exclusive features here. Consider someone uses gpu-allocator in their library crate and sets default-features = false to make it compile with a minimal set and no_std-compliance by default. They now have to enable the hashbrown feature to get it to compile.
When some other application crate uses that library crate, and also uses gpu-allocator with std feature to get backtrace support, this will now no longer compile because those are mutually exclusive.
I've suggested a change to make the hashbrown and std features coexist.

---

Can you add these lints to ensure this'll be easier to maintain in the future:

 #![warn(
    clippy::alloc_instead_of_core,
    clippy::std_instead_of_alloc,
    clippy::std_instead_of_core,
)]

And update the CI to ensure that it tests both no_std as well as std: we can add these to the matrix in the check_msrv, test and clippy jobs.

---

Finally, I ended up not spending any comments on it but instead recommend you to undo a few unnecessary import reorderings with:

cargo fmt -- --config imports_granularity=Crate --config group_imports=StdExternalCrate

The output isn't ideal (you have to group visualizer mod+use back together for example) but at least the ordering is back in check: log goes separate from the std/core/alloc "standard libraries" for example.

[MarijnS95]

Since this is a pub struct, we should probably mark this #[non_exhaustive] to always force callers to initialize it with a default:

let settings = AllocatorDebugSettings {
    log_memory_information: true,
    ..Default::default()
};

That way, any library that uses gpu-allocator with no_std will still compile when a consumer crate enables gpu-allocator with std (which enables these fields that the library crate otherwise wouldn't have set).

[MarijnS95]

As it turns out this does not work as expected outside of the crate, because of https://rust-lang.github.io/rfcs/2008-non-exhaustive.html#functional-record-updates: it assumes that a private field might be added which cannot be set with field-record-update even if only public fields are set and the rest is provided with spread syntax (..Default::default()) ¹. In other words, the only valid syntax now seems to be:

let mut settings = AllocatorDebugSettings::default();
settings.log_memory_information = true;

Let me think about possible solutions and alternatives, before likely removing #[non_exhaustive] again.

Footnotes

1. I assume because of https://rust-lang.github.io/rfcs/0736-privacy-respecting-fru.html. ↩

[MarijnS95]

Keep thiserror at 1 for now instead of pushing this drive-by change?

[CrazyboyQCD]

std can be disabled in thiserror since v2, but its msrv is 1.81+ dtolnay/thiserror#373.

But we can use derive_more instead, its msrv is 1.75+.

[CrazyboyQCD]

@MarijnS95
Should we use derive_more for bumping lower MSRV?

[MarijnS95]

Hmm we still need to look into this. IIRC there was some pushback on bumping to thiserror in some of our other repos because the crate is used incredibly frequently and requires an update throughout many (of our) crates in the ecosystem.

OTOH I don't think we require them to match to compile our code, it's just a duplicate dependency we can take on in cargo-deny.

[MarijnS95]

We're committing to a slow but steady thiserror 2 upgrade now, fine to take it in via this pull request. Would it make sense to force the thiserror/std feature when gpu-allocator/std is enabled? I have not read up on the features that it provides, nor weighed the advantages of forcing the feature on versus having downstream users lack std capabilities on returned thiserror types unless they take a dependency with "std" feature on thiserror themselves.

[MarijnS95]

Almost forgot to mention: can you please drop the chore: prefix from your commit messages? It's not used by this project and does not have any meaning in this context.

a routine task, especially a household one.

I don't think a one-off no_std conversion in a crate is considered a "routine task" 🙂

[CrazyboyQCD]

msrv is required to bump to either 1.75+(if we switch from thiserror to derive_more) or 1.81+ to get CI work.

[MarijnS95]

Nice update!

Only two things remaining: the formatting of the reports is broken, please test your changes to these before pushing them. I've suggested how to fix this in one file.

The previous review contained a request to update the CI to ensure that we test both with and without these new feature combinations, that would be very helpful to prevent breakage going forward. Right now we always build with specific backends and --no-default-features, meaning neither "hashbrown" nor "std" (nor a combination) ever gets exercised properly.

[MarijnS95]

Almost there 🤞. We just need proper and complete CI to ensure that the changes are correct as written, and most importantly: won't regress no_std support and feature combinations in the future.

Accidentally posted "Approved" instead of "Comment"

[MarijnS95]

Nice! I trust you'll be able to follow up on the remaining CI errors so that we can merge this! Do you think support for no_std needs a nice shout-out (including how to use it with default-features = false and that "hashbrown" must be used?) in the README?

I'll meanwhile look into how far we are with a thiserror 2.0 migration in our dependency tree, that might be more useful than to switch crates.

[MarijnS95]

I'm thinking of raising the MSRV unconditionally, that seems a lot less tricky to users than pretending it's 1.71, as long as they turn on the "std" feature 😅

[MarijnS95]

I've squashed everything down into a single commit because our branch protection requires every individual commit to have been signed. Even if squash-merging will squash and resign the entire PR with GitHub's "web workflow" signature anyway 🤷

Since I contributed to and approve the final result, it makes sense for me to sign such a final result (but not individual commits) :)

[Jasper-Bekkers]

Should we go ahead and merge this?