Macro `literal` fragment specifiers should forward to exact tokens
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
Motivating example (playground link):
macro_rules! foo {
($a:literal) => {
foo!(@inner $a);
};
(@inner true) => {
println!("true");
};
(@inner false) => {
println!("false");
};
}
fn main() {
foo!(true);
foo!(false);
}
The above fails to compile because literal does not forward to exact matches, but it doesn't seem like there is any reason it shouldn't. ident or tt can be used, but loosening restrictions can cause other problems.
This probably couldn't be changed without an edition depending on fallout, but we can probably make sure this works with macros 2.0.
The reference makes a comment about forwarding here: https://doc.rust-lang.org/nightly/reference/macros-by-example.html#forwarding-a-matched-fragment
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Rust Reference section on forwarding a matched fragment and the linked macros 2.0 issue to understand the existing rules and proposed context. Determine the intended behavior for literal fragments matching exact true and false tokens, including any edition or compatibility requirements; done means the behavior is specified and implemented without unintended fallout.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100