Add LLVM AllocToken and Heap Partitioning Support to the Rust compiler. - #160298
Open
rcvalle wants to merge 8 commits into
Open
Add LLVM AllocToken and Heap Partitioning Support to the Rust compiler.#160298rcvalle wants to merge 8 commits into
rcvalle wants to merge 8 commits into
Conversation
rustbot
added
A-attributes
10 tasks
rcvalle
changed the title
rcvalle
force-pushed
the
rust-heap-partitioning
branch
2 times, most recently
from
August 8, 2026 00:17
a9de07c to
170b511
Compare
Add the `-Zsanitizer=alloc-token` sanitizer option, including target support specification (i.e., `supported_sanitizers` in target specifications), and the accompanying `-Zsanitizer-alloc-token-scheme`, `-Zsanitizer-alloc-token-max`, `-Zsanitizer-alloc-token-extended`, and `-Zsanitizer-alloc-token-fast-abi` options.
Add the `#[alloc_token_hint(contains_pointers = ..., type_name = "...")]` attribute to allow the user to define the allocation token hint (i.e., the contains-pointer classification and type name encoding) for user-defined types, and the internal `#[rustc_alloc_token_hint]` attribute to annotate typed allocation functions whose type parameter identifies the allocated type.
…ning schemes Add the `rustc_sanitizers::alloc_token` module, organized and structured similarly to `rustc_sanitizers::cfi::typeid` (i.e., the `hint` module provides the interface for computing allocation token hints for a given `Ty` and dispatches to the selected heap partitioning scheme implementation, such as `type_hash_pointer_split`).
rcvalle
force-pushed
the
rust-heap-partitioning
branch
from
August 8, 2026 00:54
170b511 to
912d399
Compare
rcvalle
marked this pull request as ready for review
August 8, 2026 01:00
Collaborator
|
Some changes occurred in compiler/rustc_hir/src/attrs cc @jdonszelmann, @JonathanBrouwer Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr
cc @bjorn3 Any special-casing of Miri in the standard library requires review. cc @rust-lang/miri Some changes occurred in src/doc/unstable-book/src/compiler-flags/sanitizer.md cc @rust-lang/project-exploit-mitigations
Some changes occurred in compiler/rustc_attr_parsing cc @jdonszelmann, @JonathanBrouwer These commits modify the If this was unintentional then you should revert the changes before this PR is merged. Some changes occurred in compiler/rustc_passes/src/check_attr.rs cc @jdonszelmann, @JonathanBrouwer These commits modify compiler targets. Some changes occurred in src/tools/compiletest cc @jieyouxu |
rustbot
added
S-waiting-on-review
Member
Author
|
@bjorn3 For whenever you have time. Thank you! |
This comment has been minimized.
This comment has been minimized.
rcvalle
force-pushed
the
rust-heap-partitioning
branch
from
August 8, 2026 01:54
912d399 to
6ab006f
Compare
This comment has been minimized.
This comment has been minimized.
rcvalle
force-pushed
the
rust-heap-partitioning
branch
from
August 8, 2026 02:47
6ab006f to
d4a3185
Compare
This comment has been minimized.
This comment has been minimized.
Member
|
Has this been RFC'd or at least MCP'd? It seems to propose deep changes to the core semantics of Rust which definitely needs some wider discussion. Rust does not have typed memory, so "typed allocation" is an oxymoron. |
Member
Okay, looking at your writeup, this isn't "typed memory" / "typed allocations" at all. I can store whatever types I want into these allocations without causing UB. It's just a hint to the allocator which allocations to put near each other and which not. I would strongly recommend to avoid calling this "typed X" (which you didn't in this PR but you did in the tracking issue) since some of us in Rust have strong feelings about typed memory, and Rust is very unlikely to ever have "typed allocations" in the sense of "allocations that are required to only hold data of a certain type". The concrete API proposed here with these "tokens" seems very strange to me, but this will need a least an MCP anyway for the compiler and intrinsic part and discussion with libs-api for how to expose it and how it changes the global allocator story (and maybe lang, depending on how magic these intrinsics are -- in particular, is the type partition this induces arbitrary and we can change it any time in principle, or are we making any promises about how types are grouped and which Rust types correspond to which C types). Given that the entire project as a whole spans non-trivial changes for multiple teams, this should probably be an RFC. So I'll wait for that to properly explain to us why we need "tokens" to partition heap allocations. :) tl;dr this is a big enough change to Rust that we need to ensure the relevant teams have agreed to the general design before we start landing anything. (Also the PR looks like it could likely be split up into smaller parts which would help a lot.) |
…nt it for LLVM backend Add the `set_alloc_token_hint` and `get_alloc_token_id` methods to the backend-agnostic `BuilderMethods` trait, and implement them for the LLVM backend; and add the `SanitizeAllocToken` LLVM function attribute, and the `alloc-token-mode`, `alloc-token-max`, `alloc-token-extended`, and `alloc-token-fast-abi` module flags.
Add `alloc_typed` and `alloc_array_typed`, internal, unstable, generic allocation functions annotated with `#[rustc_alloc_token_hint]`. Route `Box::new` and `RawVec::<T, Global>::with_capacity` through them when LLVM AllocToken and heap partitioning support is enabled, so the allocation call within them is annotated with the allocation token hint (i.e., the contents of the `!alloc_token` metadata) for its type parameter `T`.
…brary Extend the Rust compiler allocator shim generation to also generate the token-enabled versions of the `__rust_alloc`, `__rust_alloc_zeroed`, and `__rust_realloc` allocation functions (i.e., `__alloc_token___rust_alloc`, `__alloc_token___rust_alloc_zeroed`, and `__alloc_token___rust_realloc`), forwarding to new unstable, token-enabled methods of the `GlobalAlloc` trait (i.e., `alloc_with_token`, `alloc_zeroed_with_token`, and `realloc_with_token`), with default implementations that ignore the token identifier and call the non-token-enabled methods, for backward compatibility with existing allocators. In the `System` allocator implementation, the token-enabled methods forward to the token-enabled C allocator interface (i.e., `__alloc_token_malloc`, `__alloc_token_calloc`, and `__alloc_token_realloc`), so that programs using the default allocator can use a token-enabled C memory allocator for the whole program, including foreign code, in mixed binaries. The token-enabled versions of these allocation functions are also added to the allocator shim exported symbols. For allocators registered with the `#[global_allocator]` attribute, the token-enabled versions of these allocation functions forward to the non-token-enabled allocation functions of the registered allocator, ignoring the token identifier, for backward compatibility with existing allocators.
Add the `alloc_token_infer` intrinsic (i.e., the Rust equivalent of the Clang `__builtin_infer_alloc_token` builtin, lowered to the `llvm.alloc.token.id` intrinsic) for allocator and arena implementers to query the token identifier for a given type at compile time (e.g., `core::intrinsics::alloc_token_infer::<T>() -> usize`), so it can be passed to a token-enabled allocator interface directly.
Add documentation for the LLVM AllocToken and heap partitioning support in the Rust compiler.
rcvalle
force-pushed
the
rust-heap-partitioning
branch
from
August 8, 2026 17:16
d4a3185 to
dfc5a28
Compare
Member
Author
Hey @RalfJung! I have a design document in the tracking issue #159111 that has all this information (and the tl;dr is that this is the implementation of the https://clang.llvm.org/docs/AllocToken.html sanitizer for Rust with matching heap partitioning schemes, and it doesn't change the language semantics or the program correctness in any way. Happy to open an MCP if you think that would be helpful. Let me know. |
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add LLVM AllocToken and heap partitioning support to the Rust compiler.
For more information about LLVM AllocToken and heap partitioning support for the Rust compiler, see the design document in the tracking issue #159111.
r? @bjorn3