Tracking issue: declarative macros 2.0

[nrc]

Tracking issue for declarative macros 2.0 (aka macro aka decl_macro aka macros-by-example).

RFC: https://github.com/rust-lang/rfcs/blob/master/text/1584-macros.md

RFC PR: rust-lang/rfcs#1584

cc @rust-lang/compiler

---

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Tasks

• Complete the draft hygiene prototype and RFC.
  • Hygiene for items, explicit imports, lexical scopes, and module scopes.
  • Hygiene for globs and trait methods (w.r.t. extension trait candidates in scope for a method call).
  • Hygiene for type directed name resolutions (i.e. methods, associated types, and fields).
  • Support macro in blocks as well as modules.
  • Implement inter-crate hygiene, except for nested macros.
  • Implement "hygiene bending" for when users want a name from macro def to "escape".
    • Examples: New declarative macros, functions and fields not being recognized #91249, Declaring modules inside decl macros 2.0 #46342
  • Implement inter-crate hygiene for nested macros (pending macro def encoding).
  • Make private_in_public hygienic?
  • Make unsafe and lints hygienic (if appropriate)?
• Add variant ast::ItemKind::MacroDef for macro_rules! items and macro items (PR syntax: add ast::ItemKind::MacroDef, simplify hygiene info #40220).
• Encode macros in the crate metadata using TokenStream, not String.
• Fix Inferred types should be checked for privacy violations #30476 (private_in_public details).
• Fix span issues If an error is not affected by a macro, don't print macro notes #30506 and Spans for Paths can be incorrect #39450 (PR macros: improve Span's expansion information #40597).
• Land macro behind a feature gate (PR Initial implementation of declarative macros 2.0 #40847).
• Future-proof matchers (e.g. $e:expr) by employing a simpler, more general grammar.
• Allow fragments (e.g. $e where $e:expr) to be parsed in more contexts (c.f. Macro matching is incorrect for macros invoked in macro expansions #26361).
• Decide whether we want macro invocations in identifier positions and/or eager expansion.
• Remove $:meta matcher (Remove $:meta matcher in decl macros #49629)

Potentially blocking issues:

• Declarative macros: no error about duplicate trait items #71614

[CryZe]

@nrc Typo in Issue Name: "issuse"

[jseyfried]

Tasks

(dtolnay edit: moved the checklist up to the OP)

[nrc]

We need to RFC a whole bunch of stuff here. In particular, I would like to propose some new syntax for declaring macros and we should RFC the changes to matchers.

[tikue]

Can the hygiene RFC mention pattern hygiene? This in particular scares me:

// Unsuspecting user's code
#[allow(non_camel_case_types)]
struct i(i64);

macro_rules! ignorant_macro {
    () => {
        let i = 0;
        println!("{}", i);
    };
}

fn main() {
    // oh no!
    ignorant_macro!();
}