What exactly is a reference/borrow under the hood? a.k.a. stack pointers vs heap pointers

I understand borrows conceptually; they're a value that is not owned and must be returned to the owner by being dropped by the borrower

That makes sense, but I don't actually understand what a reference is. I read that rust references to not perform heap allocations, but that they also are in fact pointers.

So much so that the following code can directly cast a reference to a raw heap-allocated pointer:

// owned value
let some_val = 1;

// reference
let some_ref = &some_val;

// pointer
let some_ptr = some_ref as *const i32;

// prints "1 1 1" as expected
unsafe {
    println!("{} {} {}", some_val, some_ref, *some_ptr);
}

What part of my understanding is wrong here? It is my assumption that being behind a pointer and being stack-allocated are mutually-exclusive, but am I wrong? Is the source that told me references are not heap-allocated wrong?

I guess a secondary question would be to ask what exactly the memory looks like in the above snippet ^

As far as my understanding goes, it would be as follows:

// load const 1 and store as some_val
let mut some_val = 1;

// load 1 onto the stack and invoke do_something
do_something(some_val);

// still load 1 onto the stack and invoke do_something, but ownership is not given to do_something()
do_something(&some_val);

// still load 1 onto the stack and invoke do_something & ownership is not given, but the borrow checker also makes sure that some_val is not mutably borrowed until do_something is done with &mut some_val
do_something(&mut some_val);

// allocate a copy of some_val to the heap, load a raw pointer to the new memory location onto the stack, and invoke do_something on the raw pointer. We still own some_val
do_something(&some_val as *const i32;)

I assume some part of that understanding is wrong, and I'd appreciate a correction!

> What part of my understanding is wrong here? It is my assumption that being behind a pointer and being stack-allocated are mutually-exclusive, but am I wrong?

Your understanding is incorrect. Pointers can "point" at any value in memory, including both the stack and the heap. Pointers are just an address into memory under the hood, and values that live on the stack or heap still have an address. References are just a safe abstraction on top of pointers which the borrow checker can reason about.

I'll now explain your examples:

// Owned value of `1_i32` on the stack
let some_val = 1;

// Shared (immutable) reference to `some_val`
// Implemented as a `*const i32` pointer holding `some_val` memory address
let some_ref = &some_val;

// Raw pointer to `some_val`, cast from `some_ref`
// Has the same value in memory as `some_ref`
let some_ptr = some_ref as *const i32;

// Invoke do_something, passing `some_val` by value
// Passes the value `1` directly to the function
// Ownership is given, and if the type of `some_val` is not trivially
// copyable, `some_val` will not be accessible to this scope anymore
do_something(some_val);

// Invoke do_something, passing `some_val` by shared reference
// Passes the pointer (memory address) of `some_val` to the function
// Ownership is not given, and do_something is not allowed 
// to modify the value held in `some_val`
do_something(&some_val);

// Invoke do_something, passing `some_val` by exclusive reference
// Passes the pointer (memory address) of `some_val` to the function
// Ownership is not given, but do_something is allowed
// to modify the value held in `some_val`
do_something(&mut some_val);

// Invoke do_something, passing `some_val` as a raw `*const` pointer
// Passes the pointer (memory address) of `some_val` to the function
// Ownership is not given, and do_something is not allowed 
// to modify the value held in `some_val`
// (but operations on raw pointers, requiring unsafe, are not enforced by the compiler)
do_something(&some_val as *const i32);

In memory, some_val might live at address 0xFFF0 through 0xFFF3 on the stack (4 bytes for i32). some_ref will also be allocated on the stack, placed at 0xFFE8 through 0xFFEF (8 bytes for 64-bit systems) and holding the value 0xFFF0. And the pointer could likewise be placed at 0xFFE0 through 0xFFE7 holding the same value 0xFFF0.

Of course, most compilers will optimize things so some_val could really be in a register instead of in memory on the stack and any operations using a reference or pointer to it could be inlined to use the register directly. But in terms of mental model, that isn't important.

The simple answer is that references can be thought of as pointers under the hood, though often they can be optimized away by the compiler.

Your misunderstanding is captured in this line:

> the following code can directly cast a reference to a raw heap-allocated pointer

That's not what's happening at all. Pointers can point to the heap, but they can point other places as well, including the stack, where local variables often live. (As an aside, "heap-allocated pointer" describes a pointer that exists on the heap. The term you are looking for is "pointer to a heap-allocated value.")

>
> // allocate a copy of some_val to the heap, load a raw pointer to the new memory location onto the stack, and invoke do_something on the raw pointer. We still own some_val
> do_something(&some_val as *const i32;)
>

This is incorrect; it does not allocate anything on the heap, rather it obtains a pointer to the value on the stack.