-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
builtin_macros: allow external consumers for AsmArgs parsing #92016
builtin_macros: allow external consumers for AsmArgs parsing #92016
Conversation
// Internal consumers should continue to leverage `expand_asm`/`expand__global_asm` | ||
pub fn parse_asm_args<'a>( | ||
p: &mut Parser<'a>, | ||
sess: &'a ParseSess, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Realize that it's just the handler that's currently needed for the diagnostics (source map wasn't actually needed for the initial parsing) but figured it might be easier to just pass a ref of the session anyway so that any future changes needing more from the sess could be made without requiring signature and call site updates.
Lmk if it'd be better to reduce this to just the handler though
@bors r+ |
📌 Commit 78a8e00 has been approved by |
…sing, r=Amanieu builtin_macros: allow external consumers for AsmArgs parsing As discussed in Zulip (https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/parsing.20of.20AsmArgs.20for.20inline.20assembly), we need a function entry point that rustfmt can leverage from a pre-expansion context to get a more structured representation of the asm args without having to duplicate/maintain the token stream parsing r? `@Amanieu` and/or `@joshtriplett`
…sing, r=Amanieu builtin_macros: allow external consumers for AsmArgs parsing As discussed in Zulip (https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/parsing.20of.20AsmArgs.20for.20inline.20assembly), we need a function entry point that rustfmt can leverage from a pre-expansion context to get a more structured representation of the asm args without having to duplicate/maintain the token stream parsing r? ``@Amanieu`` and/or ``@joshtriplett``
…askrgr Rollup of 7 pull requests Successful merges: - rust-lang#87901 (Fix suggestion of additional `pub` when using `pub pub fn ...`) - rust-lang#89090 (Lint bare traits in AstConv.) - rust-lang#91818 (Show the unused type for `unused_results` lint) - rust-lang#91910 (miri: lift restriction on extern types being the only field in a struct) - rust-lang#91928 (Constify (most) `Option` methods) - rust-lang#91975 (Move generator check earlier in inlining.) - rust-lang#92016 (builtin_macros: allow external consumers for AsmArgs parsing) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…acro-asm, r=cjgillot rustc_builtin_macros: make asm mod public for rustfmt Follow up to rust-lang#92016, as I'd completely missed that the mod we needed was internal
As discussed in Zulip (https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/parsing.20of.20AsmArgs.20for.20inline.20assembly), we need a function entry point that rustfmt can leverage from a pre-expansion context to get a more structured representation of the asm args without having to duplicate/maintain the token stream parsing
r? @Amanieu and/or @joshtriplett