Repository navigation
Tracking issue for dual-proc-macros #64671
Description
Activity
This might has something to do with #62558, according to the patches in termux/termux-packages#4324 (comment)
See also #62558 (comment)
Some more detailed explanation of why this feature is necessary and how it works - https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/-Z.20dual-proc-macros.
Discussed in T-compiler backlog bonanza
Our understanding is that this is a fragile bit of code in here to support cross-compiling of
rustcitself. We don't want to stabilize it as is. Its possible we want to try to get rid of it, depending on how one interprets the dialogue at #t-compiler > -Z dual-proc-macros@rustbot label: S-tracking-design-concerns S-tracking-perma-unstable
Metadata
Metadata
Assignees
Labels
Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)Area: Procedural macrosBlocker: Implemented in the nightly compiler and unstable.Category: An issue tracking the progress of sth. like the implementation of an RFCStatus: There are blocking design concerns.Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation.Status: The feature will stay unstable indefinitely.Relevant to the compiler team, which will review and decide on the PR/issue.This issue requires a nightly compiler in some way. When possible, use a F-* label instead.
Implemented in #58013
Cargo side is rust-lang/cargo#6547
This feature causes Cargo to build a proc-macro crate for both the target and the host, and for rustc to load both.
I'm not sure if this is a perma-unstable feature for the compiler-only, or if there is any need to use it elsewhere. But a tracking issue may be helpful for anyone looking for more information.