Rust Macro WG Sync meeting Oct. 6th 2023

• Q: What is the wg idea on how to organize the job
  • A: Moved the questionin another time after we run some experiments
• Q: Discussion on wg-repository: https://github.com/rust-lang/wg-macros
  • A: We would like to try keep everything on the wg page, including meeting agenda ecc. But we keep also an hackmd for informat notes like this one.
• Q: Reading club idea: https://hackmd.io/6kSbmyggT6eAy5uvdB6srA?both
  • A: All the people in the meeting think that this is a good
    idea and also help to see macros from other points of view.
  • A: Some example are: wg-macro vision, https://rust-lang.github.io/wg-async/vision.html
  • A: Perhaps we shouldn't begin directly with other languages. Instead, we could first delve into the history of our macros: Why were they designed this way? Is this the finalized version, or were certain elements omitted? What was the initial objective behind macros 2.0?
• Q: issue triage: https://rust-lang.github.io/wg-async/triage.html
  • A: We would like to discuss the issues that are already open and also to use this moment to see what sub-area of the macros we will take into consideration based on people's interest. So we start bigger and we restrict the area when we see that there is no interest in an area
• Q: We should add the wg-macros to triagebot.toml
  • Q: Reason that we will be notify for every change to the macro subsystem
  • A: What does it mean macro subsystem? the macros are really spread across the compiler, so this may be difficult to track it down. However, this can help us to understand what people in the wg are interested in what area, and what area we want left for the future. So, the final answer is to start by being notified in most of the macros subsystem with the bot and then pruning the area when there is no feedback from the wg (assuming that there is work done by other people outside of the wg).

the error for this example is lacking:

pub mod foo {
    pub mod bar {
        pub mod baz {
            #[macro_export]
            macro_rules! m {
                () => {}        
            }
        }
    }
}

foo::bar::baz::m! {}

Playground link

this makes sense, because macros 1.0 path resolution rules is very different from regular item name resolution, but it could benefit from a better explanation and note, such as a hint to use m! {} instead (since the macro was exported)

I started some work on this on my machine but hit a wall here:

https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/manually.20creating.20a.20path.20starting.20with.20.60crate.3A.3A.60

looking to pick up the work eventually but as long as I can't figure out how to create this root path I can't advance

Conclusion summary

This is a proble that looks like a Pandora's box, there are previous problem that are similar and also impact this aread like https://internals.rust-lang.org/t/pub-on-macro-rules/19358

However, due that Artur do not find any help on the general rust chat on zulip, we can resurrect the chat on the wg-macro stream and also Vincent can help with this because I was already on macro resolution code in the past. In conclusion, we discuss if it is workted spend time of improve usability on the currentl macro rule instead of moving directly to macros 2.0. As the idea of spend time on a subsystem that eventually will be replaced in the future sounds a not a good place where spend times, we think also that improve the current macro_rule in any way can help us to undestand what we want in the macros 2.0 (also reading club can help here).

On my end it's mostly pondering about these kind of 80-20 (Pareto principle) macro features which could already go a long way.

• generics may be too big of a topic for a first call, so we may want to punt on talking about it for now;

• the :empty, or more generally, :verbatim[tokens here] matcher, however, seems more tractable

  ​​​​macro_rules! example {(
  ​​​​    $($unsafe:verbatim[unsafe])? fn …
  ​​​​) => (
  ​​​​    $($unsafe)? fn
  ​​​​)}
  

Also, disclaimer that I don't know how much I may be contributing to actual compiler implementations myself, since I'm not necessarily well acquainted with compiler code; I talk and contribute mostly off user experience with macro usage.

Conclusion summary

Where do we start? Perhaps beginning with a topic like the first point might not be ideal for the wg, especially since we're just getting started. However, reflecting on the challenges of the current macros system, as mentioned in point 2, would be beneficial. At the same time, we should prioritize usability and diagnostic improvements.

I've been busy with trying to shove implement Hygiene into rust-analyzer, so far rather unsuccessful, so nothing to raise from my side.

Conclusion summary

We discuss a little bit macros resolution in rust analyzer and Hygiene, just generic chatting.