Change:
// except according to those terms. // aux-build:double.rs <ins> // aux-build:external-crate-var.rs </ins> // ignore-stage1 #![allow(unused)] #[macro_use] extern crate double; <ins> #[macro_use] extern crate external_crate_var; </ins> struct Foo; <del> macro_rules! m { () => { #[derive(Double)] struct Bar($crate::Foo); </del> <ins> trait Trait { const CONST: u32; type Assoc; } impl Trait for Foo { const CONST: u32 = 0; type Assoc = Foo; } macro_rules! local { () => { // derive_Double outputs secondary copies of each definition // to test what the proc_macro sees. mod bar { #[derive(Double)] struct Bar($crate::Foo); } mod qself { #[derive(Double)] struct QSelf(<::Foo as $crate::Trait>::Assoc); } mod qself_recurse { #[derive(Double)] struct QSelfRecurse(<<$crate::Foo as $crate::Trait>::Assoc as $crate::Trait>::Assoc); } mod qself_in_const { #[derive(Double)] #[repr(u32)] enum QSelfInConst { Variant = <::Foo as $crate::Trait>::CONST, } } </ins> } } <del> m!(); </del> <ins> mod local { local!(); } // and now repeat the above tests, using a macro defined in another crate mod external { external!{} } </ins> fn main() {}

Discussion:
The script below has a macro_rules macro that expands to: But inside of the custom derive the tokens received are: The seems to be missing. Originally reported in rustc 1.28.0-nightly ( 2018-06-02) Repro script:
The behavior is correct with rustc 1.15.0 but the current incorrect behavior exists since 1.16.0.
cc — perhaps somebody could bisect this to a specific nightly? (I guess it's too old to get a specific PR) may help here :)
Also, how does it come to happen that is still in there and not replaced during macro expansion...? Maybe I'm unclear on the phasing of how works.
Marking as P-high but don't have an assignee yet, will revisit next week when we've hopefully had a chance to bisect.
2016-12-06 has the odd result of . 2016-12-27 is the first nightly to have as the result; the previous nightly 2016-12-23 has the (correct, I presume) result.
These are the bors commits between those two nightlies ().

Auto merge of - elahn:windows-readconsole-ctrl-z, r=alexcrichton Auto merge of - japaric:do-not-delete-enable-llvm-backend, r=alexcrichton Auto merge of - YaLTeR:fastcall-fix, r=pnkfelix Auto merge of - petrochenkov:altname, r=jseyfried Auto merge of - retep998:flauschige-kaninchen, r=petrochenkov Auto merge of - brson:em, r=alexcrichton Auto merge of - jseyfried:defidvis, r=nrc Auto merge of - jseyfried:fixresolvehang, r=eddyb Auto merge of - jseyfried:fiximportresolutionbug, r=eddyb Auto merge of - steveklabnik:rollup, r=steveklabnik Auto merge of - frewsxcv:file-docs, r=brson Auto merge of - alexcrichton:fix-line-writer, r=brson Auto merge of - withoutboats:parsewherehigherrankhack, r=eddyb Auto merge of - camlorn:disablefieldreordering, r=nikomatsakis Auto merge of - jseyfried:legacycustomderivedeprecation, r=nrc Auto merge of - nrc:save-sig, r=nikomatsakis Auto merge of - Mark-Simulacrum:drop-glue, r=eddyb Auto merge of - redox-os:redoxcross, r=brson Auto merge of - jseyfried:refactorglobal_paths, r=nrc Auto merge of - brson:rm-llvm-lock, r=brson I think , , , , are possible candidates based on branch names. I'll try to run git bisect in this commit range.
I was.. largely unsuccessful at running git bisect. Maybe someone else will have more luck.
I figure it's easier to bisect the Bors commits which are sure to build correctly, rather than to run .

Overnight I ran a build of , and got the erroneous output, cutting it down to these: Auto merge of - jseyfried:legacycustomderivedeprecation, r=nrc Auto merge of - nrc:save-sig, r=nikomatsakis Auto merge of - Mark-Simulacrum:drop-glue, r=eddyb Auto merge of - redox-os:redoxcross, r=brson Auto merge of - jseyfried:refactorglobalpaths, r=nrc Auto merge of - brson:rm-llvm-lock, r=brson My money's on but I won't be able to run another build until I get to work. <details<summarySlightly modified repro script for working with such old versions of rust</summary</details
Okay, I have confirmed that exhibits the issue, and does not, so it is . cc
The following test case (replacing the similarly-named macro in the OP) helps clarify the nature of the bug. It is not "overwriting" the path component, but rather, it is missing the entire last path component (with type parameters): The is dropped: (Note: tested on nightly, because I foolishly did not keep my build of ) Edit: Additionally, only the trait path is affected. Adding before works fine. The PR is largely one refactoring commit. I've been reading through looking for the kinds of things that might enable a bug like this, but haven't found the culprit.
I have a theory. I believe this was buggy prior to jseyfried's PR, but the PR caused the bug to affect this specific test case. The following function (used exclusively by ) uses a to normalize away from paths: However, the trait path is stored in an . Prior to the PR, a path segment was deleted if (and only if) the macro was local. After the PR, a path segment is inserted if (and only if) the macro was from another crate. In each of these cases, the QSelf position field is invalidated. If my theory is correct, then prior to , it should have manifested as printing extra tokens if the definition of is moved from to . (However I no longer have the build, and I'm not sure where is successfully downloading ancient nightlies from!)

I'm downloading nightlies via cargo-bisect-rustc's bisection; I also found that for some reason rustup itself refuses to install those nightlies.
Thanks! I was able to verify my prediction; handles the original test case correctly, but duplicates the when the macro is defined locally: <details<summaryRepro with local and nonlocal macros</summary</detailsI'll start working on a PR.
Silly question: Would adding an AST type like be overkill? This pattern describes all appearances of in the AST, and I feel the most principled solution to this bug would be to add a method for this pairing of types. (whereas if I just overrode , , and in the one function linked above, it could easily get neglected the next time QSelf is somewhere) Edit: It appears that such a type in fact used to exist (), which kind of explains the bizarre name of . It was removed in for some reason. Edit 2: also perhaps libsyntax is not as malleable as I thought, due to a number of rustc plugin crates that still exist...
Since I wasn't sure about the above, I wrote two possible fixes, both of which I am now testing: A self-contained fix that makes override , but it's messy A cleaner fix that involves adding the following method to :
New delegating to by default (without changing qpaths in AST) looks like a good solution.
Thanks for the feedback! .