# Path resolution within fn

## Timeline with related documents/threads

Date | Description
-----------|-------------
2018-07-17 | Github thread from Diesel when the deprecation lint referenced here was first introduced: https://github.com/rust-lang/rust/pull/51952#issuecomment-405608959
2021-03-27 | Tracking issue 83583 filed to track deprecation lint proc_macro_derive_resolution_fallback: https://github.com/rust-lang/rust/issues/83583 (You can see proc-macro authors there bemoaning Rust's expressivity gap for this case.)
2021-04-08 | PR 84022 made PROC_MACRO_DERIVE_RESOLUTION_FALLBACK a hard error https://github.com/rust-lang/rust/pull/84022
2022-01-20 | PR 107133 reverted the aformentioned upgrade to hard error, in response to breakage found on crater (and pnkfelix's personal belief that we should aim higher here) https://github.com/rust-lang/rust/pull/107133

## The problem: `fn`-bodies and `super`

When you put a derive on a struct, such as:

#[derive(MyTrait)]
struct ModLevelStruct;

you expect it to generate some code corresponding to a trait implementation; but it might also include other helper code that the trait implementation calls out to.

Some macro authors have put such helper code into a generated submodule (though there exist other options, depending on where you are willing/able to put the aforementioned trait impl). Assuming the helper code is going into a generated submodule, you might have the above expand to:

mod _inner_mod {
    // Note the need for `super::` here,
    // to access the surrounding context.
    pub fn helper(x: &super::ModLevelStruct) { }
}
impl MyTrait for ModLevelStruct {
    fn method(&self) { _inner_mod::helper(self); }
} 

struct ModLevelStruct;

This works today when the struct and associated derive attribute occurs immediately within the body of a module (e.g. the outermost section of a Rust source file).

However, what about when you add the same `derive` to a struct that is within an `fn`-body:

fn problem() {
    #[derive(MyTrait)]
    struct FnLevelStruct;
}

which now will expand into:

fn problem() {
    mod _inner_mod {
        // Where does *this* use of `super` start
        // searching? The module that contains
        // `fn problem`, or the body of `fn problem`
        // itself?
        pub fn helper(x: &super::FnLevelStruct) { }
    }
    impl MyTrait for FnLevelStruct {
        fn method(&self) { _inner_mod::helper(self); }
    } 

    struct FnLevelStruct;
}

Today, this latter code, if written directly without using the macro expander, does not compile. (Even if it *is* written using the macro-expander, it still won't compile unless one uses a `derive`, because non-derive proc-macros are not allowed to expand into `mod` forms (see [PR #50820](https://github.com/rust-lang/rust/pull/50820)).)

Note that defining structs within a `fn`-body is not an exceptional corner case for Rust; for example, it is standard for rustdoc to turn individual code blocks into testable code by injecting them into the body of a fresh `fn`.