Leading :: semantics in macros depend on calling crate, not defining crate.

[alercah]

Easiest reproduction is to make a 2018 crate (note: rust_2018_preview is not sufficient) that calls the quote! macro:

#![feature(proc_macro_quote, proc_macro_non_items)]
use proc_macro::{quote, TokenStream}

#[proc_macro]
fn macro(input: TokenStream) -> TokenStream {
    quote! { $input }
}

This gives an error: can't find crate for `TokenStream` . Upon closer inspection, the offender is this line, and specifically, ::TokenStream::new().

The issue is that, even though hygiene dictates that this name should be looked up in the defining create, the semantics of leading :: are not accounted for. In the defining crate, in Rust 2015, it means "crate root". In the using crate, Rust 2018, it means "crate registrar" (i.e., the thing that holds crate names).

@petrochenkov, does this impact the stabilization of Span? I don't understand how hygeine works when a path has multiple pieces (identifiers or colons) from different caller/definer contexts. (Aside: I would prefer some elucidation for eventual documentation purposes.)

See also #44660. I don't think it impacts $crate at all, but I'm not sure.

[petrochenkov]

This looks very similar to #50376.

does this impact the stabilization of Span?

Well, yes and no.
On one hand, we are stabilizing only Span::call_site in macros 1.2 that doesn't provide anything fundamentally new compared with long stable proc macro derives.
On another hand, the problem already affects proc macro derives as well.
This rather blocks stabilization of --edition or specific features that need cross-edition compatibility, like the "module reform".

This is all annoying. Edition compatibility is not even part of the language, in theory we could provide it on best-effort basis, but in practice it forces our hand in decisions like #50376.
So many unnecessary problems followed from one single decision to allow large scale breakage / semantic changes across editions at all.

[alercah]

Yes, this does look a lot like #50376. As it is, it is definitely blocking the stabilization of proc_macro_quote, but that's an implementation nit that can be tweaked there (and, in fact, I'd appreciate if you could do so).

I unfortunately don't fully understand the current hygiene rules, and in particular how they interact with each other and with new features, in large part because they aren't well-documented. Do you use any live chat medium that I could use to talk things over and pick your brain on? I could put a bunch of thoughts into an issue like this but I imagine much has been tread over already.

(In the meanwhile, I think we should fix proc_macro::quote so that it's usable from 2018.)

[petrochenkov]

Do you use any live chat medium

Not really.
Compiler team is testing out various chats now for possible migration, e.g. https://rust-lang.zulipchat.com, so we can try that.

[djrenren]

@petrochenkov Any update on this?

[petrochenkov]

No updates, but #50376 (comment) and #50376 (comment) describe reasonable rules that can be implemented to address this issue.

[petrochenkov]

Closed by #56053