Are dependency injection containers that return references to values allocated in a local function fundamentally impossible in Rust?

You can try making a drop guard along with Box::leak to leak a reference to live long enough, then have custom behavior on Drop to reclaim the leaked memory. Note that this will require you to do everything through the drop guard:

use std::marker::PhantomData;
use std::mem::ManuallyDrop;

struct ComplexThing<'a>(&'a i32);

struct Module;

pub struct DropGuard<'a, T: 'a, V: 'a> {
    // do NOT make these fields pub
    // direct manipulation of these is very unsafe
    container: ManuallyDrop<T>,
    value: *mut V,
    // I'm not sure this is needed but better safe than sorry
    _value: PhantomData<&'a mut V>,
}

impl<'a, T: 'a, V: 'a> DropGuard<'a, T, V> {
    pub fn new<F: FnOnce(&'a mut V) -> T>(value: Box<V>, gen: F) -> Self {
        // leak the value so it lives long enough
        let leaked = Box::leak(value);
        // get a pointer to know what to drop
        let leaked_ptr: *mut _ = leaked;
        DropGuard {
            container: ManuallyDrop::new(gen(leaked)),
            value: leaked_ptr,
            _value: PhantomData,
        }
    }
}

// so you can actually use it
// no DerefMut since dropping the container without dropping the guard is weird
impl<'a, T: 'a, V: 'a> std::ops::Deref for DropGuard<'a, T, V> {
    type Target = T;

    fn deref(&self) -> &Self::Target {
        &self.container
    }
}

impl<'a, T: 'a, V: 'a> Drop for DropGuard<'a, T, V> {
    fn drop(&mut self) {
        // drop the container first
        // this should be safe since self.container is never referenced again
        // the value its borrowing is still valid (due to not being dropped yet)
        // and there should be no references to it (due to this struct being dropped)
        unsafe {
            ManuallyDrop::drop(&mut self.container);
        }
        // now drop the pointer
        // this should be safe since it was created with Box::leak
        // and the container borrowing it has already been dropped
        // and no more references should have survived
        std::mem::drop(unsafe { Box::from_raw(self.value) });
    }
}

impl Module {
    pub fn resolve_foo(&self) -> i32 {
        5
    }

    pub fn resolve_complex_thing_1(&self) -> DropGuard<ComplexThing, i32> {
        DropGuard::new(Box::new(self.resolve_foo()), |i32_ref| {
            ComplexThing(i32_ref)
        })
    }
}

fn main() {
    let module = Module;
    let guard = module.resolve_complex_thing_1();
    println!("{:?}", guard.0);
}

Playground link

Another way that also cleans up the typing is to use a trait:

use std::marker::PhantomData;
use std::mem::ManuallyDrop;

struct ComplexThing<'a>(&'a i32);

struct Module;

// not sure if this trait should be unsafe
// but again, better safe than sorry
pub unsafe trait Guardable {
    type Value;
}

unsafe impl Guardable for ComplexThing<'_> {
    type Value = i32;
}

pub struct DropGuard<'a, T: 'a + Guardable> {
    // do NOT make these fields pub
    // direct manipulation of these is very unsafe
    container: ManuallyDrop<T>,
    value: *mut T::Value,
    // I'm not sure this is needed but better safe than sorry
    _value: PhantomData<&'a mut T::Value>,
}

impl<'a, T: 'a + Guardable> DropGuard<'a, T> {
    pub fn new<F: FnOnce(&'a mut T::Value) -> T>(value: Box<T::Value>, gen: F) -> Self {
        // leak the value so it lives long enough
        let leaked = Box::leak(value);
        // get a pointer to know what to drop
        let leaked_ptr: *mut _ = leaked;
        DropGuard {
            container: ManuallyDrop::new(gen(leaked)),
            value: leaked_ptr,
            _value: PhantomData,
        }
    }
}

// so you can actually use it
// no DerefMut since dropping the container without dropping the guard is weird
impl<'a, T: 'a + Guardable> std::ops::Deref for DropGuard<'a, T> {
    type Target = T;

    fn deref(&self) -> &Self::Target {
        &self.container
    }
}

impl<'a, T: 'a + Guardable> Drop for DropGuard<'a, T> {
    fn drop(&mut self) {
        // drop the container first
        // this should be safe since self.container is never referenced again
        // the value its borrowing is still valid (due to not being dropped yet)
        // and there should be no references to it (due to this struct being dropped)
        unsafe {
            ManuallyDrop::drop(&mut self.container);
        }
        // now drop the pointer
        // this should be safe since it was created with Box::leak
        // and the container borrowing it has already been dropped
        // and no more references should have survived
        std::mem::drop(unsafe { Box::from_raw(self.value) });
    }
}

impl Module {
    pub fn resolve_foo(&self) -> i32 {
        5
    }

    pub fn resolve_complex_thing_1(&self) -> DropGuard<ComplexThing> {
        DropGuard::new(Box::new(self.resolve_foo()), |i32_ref| {
            ComplexThing(i32_ref)
        })
    }
}

fn main() {
    let module = Module;
    let guard = module.resolve_complex_thing_1();
    println!("{:?}", guard.0);
}

Playground link

Since every container should only have one valid DropGuard value type, you can put that in an associated type in a trait, so now you can work with DropGuard<ComplexThing> instead of DropGuard<ComplexThing, i32>, and this also prevents you from having bogus values in the DropGuard.

Disclaimer: I'm fairly new to Rust; this answer is based on limited experience and may be un-nuanced.

As a general principle of Rust program design — not specific to dependency injection — you should plan not to use references except for things that are one of:

• temporary, i.e. confined to the life of some stack frame (or technically longer than that in the case of async functions, but you get the idea, I hope)
• compile-time constants or lazily initialized singletons, i.e. &'static references

The reason is that Rust does not — without various trickery — support lifetimes that are not one of those two cases.

Any structures which are needed for longer durations than that should be designed to not contain non-'static references — and instead use owned values. In other words, let your DI be like

pub trait ResolveOwn<T: 'static> {
//                   ^^^^^^^^^^
    fn resolve(&self) -> T;
}

Don't actually add that lifetime constraint: it doesn't buy you anything, and might be inconvenient (for example, in a test that wants to inject things referring to the test — which will work fine since they live longer than the entire DI container — or if the application's actual main() has something to share, similarly). But plan as if it were there.

Given this constraint, how can you implement things that seem to want references?

• In the simplest cases, just use owned values and don't worry about any extra cloning required unless it proves to be a performance issue.
• Use Rc or Arc for reference-counted smart pointers that keep things alive as long as necessary.
• If some T really requires references, but only into its own data, use a safe self-referential struct helper like ouroboros. (I believe this is similar to but more general than the suggestion in Aplet123's answer to this question.)

All of these strategies are independent of the DI container: they're ways to make a type satisfy the 'static lifetime bound ("contains no references except 'static ones").