Declarative macro transcription does not take into account precedence
Nobody has claimed this yet.
- Dominant language
- reStructuredText
- Stars
- 497
- Forks
- 41
- Avg merge
- 3h 52m
- Merged PRs (30d)
- 4
Description
Let's consider the following code:
macro_rules! two_times {
($e:expr) => {
2 * $e
};
}
fn main() {
let a = two_times!(1 + 1);
assert_eq!(a, 4);
}
Let's break down its expansion according to the current Ferrocene specs:
$ematches the expression1 + 1(20.4.1.2:6),- When transcribing,
$eis replaced with1 + 1(20.4.2:3), - The final expansion is
2 * 1 + 1.
Well, that's not what currently happens (playground link). rustc -Zunpretty=expanded even adds parenthesis around the 1 + 1.
My understanding as that expr metavariables that match an arithmetic expression should have a higher precedence than the rest of the macro substitution. As far as I can tell, this is not mentioned in Ferrocene.
Side note: I don't have much experience in how Ferrocene specs are structured, so I may have used the wrong word/missed something important. Sorry for that.
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 linked Ferrocene sections on macro metavariables, transcription, arithmetic expressions, and expression precedence. Compare the documented expansion of the two_times! example with rustc -Zunpretty=expanded and determine how precedence should be specified; done means the specification accounts for the observed parenthesized expansion.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers, documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100