No, it isn't. Because that distinction is significant if you are using the language in an environment where those libraries are not available or suitable, such as the Linux project which uses a custom fork of Alloc which provides collections for different allocators.
So, that is not done at the language level but the library level. Unless the compiler is modified for Linux, but even if it is, that's entirely bespoke and unstable. This is not comparable to Zig's design. I'm aware that anything can be done if the right things are implemented; I'm talking about what Rust-the-language currently does for control over allocation. If the answer comes down to "we're doing something custom", then the language is soewhat or largely sidestepped. C-the-language certainly doesn't have panics or exceptions, even though longjmp or a custom runtime could be used.
Rust the language knows nothing about allocations. It’s purely a library concern.
For the time being, I consider alloc and std to be part of the language, and the compiler also has provisions for them if they are used. If the alternative is supposed to be only using core, then the language does not provide for control over allocations the way Zig does. Imposing allocations with no control and not providing allocations at all are both failure modes. With enough effort, anyone could do anything, but programming languages exist to control and enhance certain things under their purview. Rust does not have a comparable facility to control allocations like it controls ownership and borrowing. Just as C-with-tooling being safe isn't the same as C being safe, Rust-with-libraries providing control over allocations isn't the same as Rust providing control over allocations.