Wrong span of Path if ModSep is inserted by proc macro

[Y-Nak]

I tried this code:

// macros/src/lib.rs
use proc_macro::TokenStream;
use quote::quote;
use syn::parse_macro_input;

#[proc_macro_derive(use_self)]
pub fn use_self(input: TokenStream) -> TokenStream {
    let item: syn::ItemEnum = parse_macro_input!(input);
    let ident = item.ident;
    let var0 = item.variants[0].ident.clone();
    TokenStream::from(quote! {
        #[automatically_derived]
        impl #ident {
            fn foo() -> Self {
                #ident::#var0
            }
        }
    })
}

// src/lib.rs
use macros::use_self;
#[derive(use_self)]
pub enum Direction {
    East,
}

Currently, the Span::ctxt() of Direction::East in the expansion is equal to SyntaxCtxt::root(). But this is obviously wrong because :: is inserted by the macro.

This would be because the span of :: is ignored in

rust/compiler/rustc_parse/src/parser/path.rs

Lines 149 to 157 in d68f7a2

	let lo = self.token.span;
	let mut segments = Vec::new();
	let mod_sep_ctxt = self.token.span.ctxt();
	if self.eat(&token::ModSep) {
	segments.push(PathSegment::path_root(lo.shrink_to_lo().with_ctxt(mod_sep_ctxt)));
	}
	self.parse_path_segments(&mut segments, style)?;
	Ok(Path { segments, span: lo.to(self.prev_token.span), tokens: None })

[Aaron1011]

It doesn't look like there's anything wrong with that parsing code - mod_sep_ctxt is getting used correctly.

I think the problem is that we end up needing to join spans with different SyntaxContexts to produce the full span of Direction::East. There isn't an obvious best choice here - we can either pick SyntaxContext::root() and ignore the macro ctxt from the ::, or pick the macro ctxt and ignore the ctxt from Direction and East

[Y-Nak]

I mean, lo.to(self.prev_token.span) seems incorrect because it ignores the context of :: and PathSegment in between.

Consider A::B::C where A and C have root context and B doesn't, in this case I think A::B::C shouldn't have root context because the path itself results from macro expansion.
Also, comment of the current implementation of Span::to says

Return the macro span on its own to avoid weird diagnostic output. It is preferable to have an incomplete span than a completely nonsensical one.

The result of parse_path seems inconsistent with it.