Skip to content

Conversation

@clarfonthey
Copy link
Contributor

Ultimately, it would be ideal to make HashTable the canonical "raw" API that HashMap and HashSet are based upon.

However, the alloc module will still be needed by everything, and because there would be a name conflict with external crate alloc, we'll name it alloc2 instead and hoist it out of the raw module.

(I could have given it a much cringier name, like ourlloc, but I decided not to in this case.)

@Amanieu
Copy link
Member

Amanieu commented Jan 7, 2026

I don't understand the issue with the name conflict. Our module is crate::alloc while the crate is ::alloc.

@clarfonthey
Copy link
Contributor Author

extern crate alloc inside std/lib.rs specifically sets crate::alloc to ::alloc, so, we can't use it if we keep that.

However, I believe that this is no longer necessary with the latest MSRV, so, we could probably remove it? I'll poke around.

@clarfonthey clarfonthey force-pushed the alloc2 branch 3 times, most recently from 210eb06 to c9b8ea7 Compare January 9, 2026 06:29
@clarfonthey
Copy link
Contributor Author

clarfonthey commented Jan 9, 2026

So, we can't remove the extern crate alloc, but we can rename it to extern crate alloc as stdalloc, which I guess is okay.

The bottom line is that the "extern prelude" can be modified by cargo and rust flags, but when modifying it in code, it has to add the crate name into the symbol namespace at the root of the crate; this is not possible to do otherwise. rust-lang/rfcs#3875 will make this not a requirement, but, for now, it is one.

@clarfonthey clarfonthey changed the title Move crate::raw::alloc into crate::alloc2 Move crate::raw::alloc into crate::alloc Jan 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants