proc_macro! expansion can refer to items defined in the root w/o importing them

[japaric]

Apologies if this has already been reported; I didn't search too hard.

STR

// bar/src/lib.rs

#![feature(proc_macro)]

extern crate proc_macro;
#[macro_use]
extern crate quote;

use proc_macro::TokenStream;

#[proc_macro]
pub fn bar(_: TokenStream) -> TokenStream {
    quote!(mod __bar {
        // NOTE `Foo` is never imported in this module
        static mut BAR: Option<Foo> = None;
    }).into()
}

// foo/src/lib.rs

#![feature(proc_macro)]

extern crate bar;

use bar::bar;

struct Foo;

bar!();

This code compiles but I would expect it not to because the expanded form doesn't compile:

// foo/src/lib.rs -- `cargo expand`-ed and cleaned up
struct Foo;

mod __bar {
    static mut BAR: Option<Foo> = None;
}

$ cargo build
error[E0412]: cannot find type `Foo` in this scope
 --> src/lib.rs:4:28
  |
4 |     static mut BAR: Option<Foo> = None;
  |                            ^^^ not found in this scope
help: possible candidate is found in another module, you can import it into scope
  |
4 |     use Foo;
  |

error: aborting due to previous error

Meta

$ rustc -V
rustc 1.27.0-nightly (428ea5f6b 2018-05-06)

cc @jseyfried

[alexcrichton]

@petrochenkov do you know if this might be related to #50050? The hygiene here is indeed quite suspicious

[petrochenkov]

This looks like a different issue to me at a first glance (but we need to check on older releases whether this is a regression or not).
Or even two issues?
First, isn't quote supposed to have def-site hygiene? Here it exhibits something call-site-like.
Second, the bar's call-site location (in module system), in which Foo is in scope, is somehow mixed up with its call-site hygienic context.
At least quote! is not stabilized.

[alexcrichton]

@petrochenkov oh this is using the quote crate, not the one in proc_macro

[alexcrichton]

Looks like this is a bug on stable Rust --

// foo.rs
#![crate_type = "proc-macro"]

extern crate proc_macro;

use proc_macro::*;

#[proc_macro_derive(Foo)]
pub fn foo1(a: TokenStream) -> TokenStream {
    drop(a);
    "mod __bar { static mut BAR: Option<Something> = None; }".parse().unwrap()
}

// bar.rs
#[macro_use]
extern crate foo;

struct Something;

#[derive(Foo)]
struct Another;

fn main() {}

$ rustc +stable foo.rs && rustc +stable bar.rs -L .
... only warnings printed

[alexcrichton]

cc @nrc, you may want to take a look at this as well, especially because it's a bug on stable Rust which fixing may cause a lot of regressions

[nrc]

This looks correct to me - aiui we use call-site hygiene for proc macros, and so we're using the hygiene context from where bar! is written to resolve the name Foo, and it does exist there. Long term, we should be using def-site hygiene here and so it wouldn't compile because there is no Foo where bar is defined.

[alexcrichton]

@nrc hm but we've been advocating that "hygiene" in expanded macros for 1.1/1.2 is basically "copy/paste" hygiene, but in this case it's not?

[nrc]

No, this is very much a limitation of the hygiene algorithm here - in the proper hygiene setup when you create a new scope in a macro, you get a combination of the hygiene info for the new scope plus the 'base scope'. The intuition you want is that the base scope is the call-site (that gives 'copy and paste' hygiene). However, the macros 1.1/1.2 algorithm is essentially the base scope everywhere (i.e., we ignore any scopes introduced by the macro) and the base scope is the call site.

[petrochenkov]

@nrc
How do you plan to move to the "proper hygiene setup" from the current scheme (which seems incorrect/underimplemented to me) if proc_macro/proc_macro_attribute are stabilized now?

[petrochenkov]

Even more alarming example:

// foo.rs
#![crate_type = "proc-macro"]
extern crate proc_macro;
use proc_macro::*;

#[proc_macro_derive(Foo)]
pub fn foo1(_: TokenStream) -> TokenStream {
    "
    struct Outer;
    mod inner {
        type Inner = Outer; // `Outer` shouldn't be available from here
    }
    ".parse().unwrap()
}

// bar.rs
#![allow(unused)]

#[macro_use]
extern crate foo;

#[derive(Foo)] // OK?!
struct Dummy;

fn main() {}

I.e. the current implementation of call-site hygiene effectively flattens any module structures existing inside the macro.

[petrochenkov]

Perhaps we need to add some extra feature gate for macros generating modules?
(Possibly retroactively affecting proc_macro_derive).
Non-module scoping is not affected as far as I can conclude from some quick experiments.

[alexcrichton]

Yeah if this is the current state of hygiene then I'd want to definitely gate modules from being in the output of procedural macros and procedural attributes. I'd ideally prefer to aggressviely start warning against modules in the output of custom derive as well.