is it possible to assert_compile_fail! { extern crate alloc; }? we know you can fork() the compiler but we don't know how to go from that to assert_compile_fail, and we need it to work on windows too...
It can mark doctests with compile_fail - as far as I know there's no way to do it with a regular test.
You could use autocfg in a build script and assert on probe_sysroot_crate.
3 Likes
We need it to be an item macro, so as not to require user intervention. See also Code review request: `allocdeny` 0.1.0 for motivation, we're trying to explore all our options for how to do the thing.
(See also New signal-safe std replacement, looking for contributors to help reimplement all of std for even more background/motivation)
If you're providing a library crate, you can include the "alloc doesn't exist" check in that library's build script, and no user intervention is necessary, since the build script is required for your library to build.
If you only want to do it sometimes, that can be a crate feature flag.
Alternatively, figure it out in the build script and export a macro that alternatively expends to nothing or a compile_error!, such that using that macro only works when alloc is/isn't available.
1 Like
can a build script do that and not be trivially bypassed? also we're not sure we want an "alloc is available" check, we were trying to go for "alloc is used" so it could be used on an unmodified toolchain(?)...
If your threat model includes people building your crate incorrectly, you're far outside the Rust + Cargo model.
The buildscript knows the exact toolchain being used to compile both it (host) and its crate's (target) code. Mixing toolchains in one artifact is UB, thus whether alloc is available to the target triple is a known value constant throughout all of the compilation process.
Even with a cfg(accessible) to check whether ::alloc is nameable in a given context, this is an impossible ask, since a different crate (upstream or downstream) can use alloc/std. A global concern must be addressed globally. Even if you're the final binary artifact crate, the only way to test that std or alloc aren't used is to compile for a target without the stdroot crate in question (much to the annoyance of no_std libraries that want to ensure they're std free.)
You can maybe bodge a partial solution by using a global allocator that fails to link (e.g. removing the __rust_alloc symbol), but that only can break global allocation, not other signal-unsafe std assumptions that don't utilize the global allocator.
1 Like
but if alloc is part of the sysroot...
can you use different sysroots with the same toolchain? (can you mix sysroots?)
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.