Cannot refer to item inside function from module inside function

[davidhewitt]

I tried this code (https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8c1861ee7e07799c5897f37f0aa2f849):

fn main() {
    mod foo {
        use super::*;
        
        fn foobar() {
            bar();
        }
    }
    
    fn bar () {}
}

This fails to compile:

error[E0425]: cannot find function `bar` in this scope
 --> src/main.rs:6:13
  |
6 |             bar();
  |             ^^^ not found in this scope

warning: unused import: `super::*`
 --> src/main.rs:3:13
  |
3 |         use super::*;
  |             ^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

rustc --version --verbose:

rustc 1.48.0 (7eac88abb 2020-11-16)
binary: rustc
commit-hash: 7eac88abb2e57e752f3302f02be5f3ce3d7adfb4
commit-date: 2020-11-16
host: x86_64-unknown-linux-gnu
release: 1.48.0
LLVM version: 11.0

Also reproduces on current nightly (as of 2020-11-21).

---

I suspect that what's going on is that use super::* doesn't actually resolve to the scope inside fn main, but instead the surrounding scope fn main is itself in.

I tried to search around other issues to find whether this is expected.

This is a super weird special case. It seems plausible (at least to me) that use super::* from a module inside a function should bring other items local to that function into scope.

[davidhewitt]

(If the lang team agrees that this code should compile, I'm willing to attempt a patch to fix.)

[jonas-schievink]

Note that fixing this would break this code:

fn main() {
    mod foo {
        use super::*;
        
        fn foobar() {
            bar();
        }
    }
}

fn bar() {}

[davidhewitt]

I'm not convinced it would break that code; bar is already a valid identifier inside fn main and so I would argue use super::*; inside main::foo should resolve fn bar in that case too.

[davidhewitt]

I can find another example of this which is easy to reproduce and seems like a much more likely case to trigger!

Write a doctest which declares a module inside it:

/// ```rust
/// struct Foo;
///
/// mod foobar {
///     use super::*;
///
///     fn bar() -> Foo { Foo }
/// }
///
/// ```
fn foo() {}

This doctest will fail to compile:

---- src/lib.rs - foo (line 1) stdout ----
error[E0412]: cannot find type `Foo` in this scope
 --> src/lib.rs:7:17
  |
8 |     fn bar() -> Foo { Foo }
  |                 ^^^ not found in this scope

error[E0425]: cannot find value `Foo` in this scope
 --> src/lib.rs:7:23
  |
8 |     fn bar() -> Foo { Foo }
  |                       ^^^ not found in this scope

I would guess that the doctest framework wraps the doctest code inside a function, so we see exactly the same issue as in my original report.

[davidhewitt]

Ah, but I think this variation of @jonas-schievink 's example will break:

fn main() {
    mod foo {
        use super::*;
        
        fn foobar() {
            bar();
        }
    }

    fn bar() {
        println!("inner bar");
    }
}

fn bar() {
    println!("outer bar");
}

At the moment it always prints "outer bar", but if we fixed my original example this would either be ambiguous or print "inner bar", I asssume.

(We could perhaps make it backwards compatble by letting items outside the function take precedence, and then switch the order to prefer items inside the function on an edition change.)

[Havvy]

I am against changing the meaning of super.

I also wouldn't call this a bug. Everything is working as it originally is intended to. super refers to the parent module, not the parent item scope. Functions allow defining items that are local to the function and a module is non-local, even if it's declared inside the function.

IMO, if you need a module, just like if you need an impl, it should not be defined in a function.

[petrochenkov]

We probably need some way to refer to block-that-are-parent-of-modules, but super is not that way.
super has a well-defined meaning - parent mod, similarly to how self is the current module and not current block or something.

Besides being a breaking change, path resolving to an unnamed block is some new possibility that will cause a number of subsequent issues.
What would happen here, for example

use super as foo; // referes to a block
let bar = foo;

[petrochenkov]

My preferred solution to this issue is probably #[transparent] mod foo { ... } that prevent the module from introducing a "name barrier".
It's something that is more useful in various situations, and fits more naturally into the existing system.

UPD: Example.

struct S;

#[transparent]
mod m {
    fn f() {
        let s = S; // OK
    }
}

[davidhewitt]

#[transparent] attribute is a very compelling proposal 👍. It would be a shame that it would be needed in some doctest examples. Still great as a 100% backwards-compatible opt-in design.

I wrote a PR to experiment with what I proposed above (#79309) - I've added an alternatives section with #[transparent].

[AndreySmirnov81]

I would like to see this result:

1. For Rust before 2024 edition

fn main() {
    mod foo {
        use super::*;
        
        fn foobar() {
            bar(); // <- error[E0425]: cannot find function `bar` in this scope
        }
    }

    fn bar() {
        println!("inner bar");
    }
}

error[E0425]: cannot find function bar in this scope

2. For Rust before 2024 edition

fn main() {
    mod foo {
        use super::*;
        
        fn foobar() {
            bar();
        }
    }

    fn bar() {
        println!("inner bar");
    }
}

fn bar() {
    println!("outer bar");
}

outer bar

3. For Rust before 2024 edition

fn main() {
    #[enable_fn_scope_from_inner_module] // <- !!!
    mod foo {
        use super::*;
        
        fn foobar() {
            bar();
        }
    }

    fn bar() {
        println!("inner bar");
    }
}

fn bar() {
    println!("outer bar");
}

inner bar

4. For Rust before 2024 edition

#![enable_fn_scope_from_inner_module] // <- !!!

fn main() {
    mod foo {
        use super::*;
        
        fn foobar() {
            bar();
        }
    }

    fn bar() {
        println!("inner bar");
    }
}

fn bar() {
    println!("outer bar");
}

inner bar

5. For Rust 2024 edition

fn main() {
    mod foo {
        use super::*;
        
        fn foobar() {
            bar();
        }
    }

    fn bar() { // <- obscures the outer bar
        println!("inner bar");
    }
}

fn bar() {
    println!("outer bar");
}

inner bar

[AndreySmirnov81]

Alternatively, for this non-working example:

we can use this:

However, there were difficulties with rust-analyzer: rust-lang/rust-analyzer#15805

[Veetaha]

Here is a real use case for this. I'd like to generate a child module in a proc macro where I'd place the definition of the builder stuct (for privacy of its fields). The builder's fields should reference types from the surrounding scope.

fn example() {
    struct Password(String);

    // Suppose a `#[builder]` proc macro was placed on this struct
    struct User {
        password: Password,
    }

    // This module is generated by the proc-macro
    mod user_builder {                  
        use super::*;                   

        pub(super) struct UserBuilder { 
            password: Option<Password>, 
        }                               
    }                                   
}

I made an article about this problem here: https://elastio.github.io/bon/blog/the-weird-of-function-local-types-in-rust

[sunshowers]

Another, similar use case for this is with a new feature in our HTTP server Dropshot called API traits. Applying this proc macro on the trait causes a bunch of support functions (and soon at least one macro) to be generated. The options are:

• Put the generated items at the top-level, polluting the top-level namespace in an undesirable way.
• Hang the items off of a type (e.g. enum SupportFunctions {}, then impl SupportFunctions { ... }). This would work for functions but not for macros.
• Put them in a support module. That's what we've chosen, but this runs into the issue described here.

The proposal to have a way to mark a module as transparent in this comment above would solve this issue, and I think it would be worth pursuing.

[Veetaha]

@sunshowers I've since discovered another option to workaround this problem, if your goal is to make the generated symbols private. You can just randomize the names of your generated symbols using some simple randomness source like std's RandomState (example).

This way the users won't be able to use the generated names, and even if they do, they won't be able to compile/re-compile the code if they do that. I also recommend marking these symbols with #[deprecated] to further complicate their usage.

[sunshowers]

@sunshowers I've since discovered another option to workaround this problem, if your goal is to make the generated symbols private. You can just randomize the names of your generated symbols using some simple randomness source like std's RandomState (example).

This way the users won't be able to use the generated names, and even if they do, they won't be able to compile/re-compile the code if they do that. I also recommend marking these symbols with #[deprecated] to further complicate their usage.

Ah, in my case I'd like the generated symbols to be public.