public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Thomas Schwinge <tschwinge@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc/devel/rust/master] macro: Allow builtin `MacroInvocation`s within the AST Date: Mon, 13 Feb 2023 12:02:00 +0000 (GMT) [thread overview] Message-ID: <20230213120200.10A1038493C9@sourceware.org> (raw) https://gcc.gnu.org/g:b9501cbe2624a80365e33550fc92035620a64e7b commit b9501cbe2624a80365e33550fc92035620a64e7b Author: Arthur Cohen <arthur.cohen@embecosm.com> Date: Wed Jan 18 12:23:03 2023 +0100 macro: Allow builtin `MacroInvocation`s within the AST This commit turns AST::MacroInvocation into a sum type. The class can now represent a regular macro invocation (lazily expanded) or a builtin one (eagerly expanded) gcc/rust/ChangeLog: * expand/rust-macro-builtins.cc (make_macro_invocation): Add short hand function for returning fragments containing macro invocations. (MacroBuiltin::compile_error_handler): Add explanation for eager invocation Diff: --- gcc/rust/expand/rust-macro-builtins.cc | 72 +++++++++++++++++++++++++++++++++- 1 file changed, 71 insertions(+), 1 deletion(-) diff --git a/gcc/rust/expand/rust-macro-builtins.cc b/gcc/rust/expand/rust-macro-builtins.cc index f6ddb1a803e..11b5d5fbc9d 100644 --- a/gcc/rust/expand/rust-macro-builtins.cc +++ b/gcc/rust/expand/rust-macro-builtins.cc @@ -37,8 +37,39 @@ make_string (Location locus, std::string value) PrimitiveCoreType::CORETYPE_STR, {}, locus)); } -/* Match the end token of a macro given the start delimiter of the macro */ +// TODO: Is this correct? +static std::unique_ptr<AST::Expr> +make_macro_invocation (AST::BuiltinMacro kind, AST::DelimTokenTree arguments) +{ + std::string path_str; + + switch (kind) + { + case AST::BuiltinMacro::Assert: + case AST::BuiltinMacro::File: + case AST::BuiltinMacro::Line: + case AST::BuiltinMacro::Column: + case AST::BuiltinMacro::IncludeBytes: + case AST::BuiltinMacro::IncludeStr: + case AST::BuiltinMacro::CompileError: + case AST::BuiltinMacro::Concat: + path_str = "concat"; + break; + case AST::BuiltinMacro::Env: + case AST::BuiltinMacro::Cfg: + case AST::BuiltinMacro::Include: + break; + } + return AST::MacroInvocation::builtin ( + kind, + AST::MacroInvocData (AST::SimplePath ( + {AST::SimplePathSegment (path_str, Location ())}), + std::move (arguments)), + {}, Location ()); +} + +/* Match the end token of a macro given the start delimiter of the macro */ static inline TokenId macro_end_token (AST::DelimTokenTree &invoc_token_tree, Parser<MacroInvocLexer> &parser) @@ -386,6 +417,45 @@ MacroBuiltin::compile_error_handler (Location invoc_locus, /* Expand builtin macro concat!(), which joins all the literal parameters into a string with no delimiter. */ +// This is a weird one. We want to do something where, if something cannot be +// expanded yet (i.e. macro invocation?) we return the whole MacroInvocation +// node again but expanded as much as possible. +// Is that possible? How do we do that? +// +// Let's take a few examples: +// +// 1. concat!(1, 2, true); +// 2. concat!(a!(), 2, true); +// 3. concat!(concat!(1, false), 2, true); +// 4. concat!(concat!(1, a!()), 2, true); +// +// 1. We simply want to return the new fragment: "12true" +// 2. We want to return `concat!(a_expanded, 2, true)` as a fragment +// 3. We want to return `concat!(1, false, 2, true)` +// 4. We want to return `concat!(concat!(1, a_expanded), 2, true); +// +// How do we do that? +// +// For each (un)expanded fragment: we check if it is expanded fully +// +// 1. What is expanded fully? +// 2. How to check? +// +// If it is expanded fully and not a literal, then we error out. +// Otherwise we simply emplace it back and keep going. +// +// In the second case, we must mark that this concat invocation still has some +// expansion to do: This allows us to return a `MacroInvocation { ... }` as an +// AST fragment, instead of a completed string. +// +// This means that we must change all the `try_expand_many_*` APIs and so on to +// return some sort of index or way to signify that we might want to reuse some +// bits and pieces of the original token tree. +// +// Now, before that: How do we resolve the names used in a builtin macro +// invocation? +// Do we split the two passes of parsing the token tree and then expanding it? +// Can we do that easily? AST::Fragment MacroBuiltin::concat_handler (Location invoc_locus, AST::MacroInvocData &invoc) {
next reply other threads:[~2023-02-13 12:02 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-02-13 12:02 Thomas Schwinge [this message] -- strict thread matches above, loose matches on Subject: below -- 2023-01-30 17:24 Thomas Schwinge
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20230213120200.10A1038493C9@sourceware.org \ --to=tschwinge@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).