Probably because expansion happens when an argument appears in the macro body, for instance:
#define FOO(x) tok_##x // FOO(__FILE__) expands to tok___FILE__ #define BAR(x) FOO(x) // BAR(__FILE__) is invalid; tries to expand tok_"/path/to/the/file" On Thu, Dec 29, 2016 at 9:29 AM, Micah Hainline via swift-dev < swift-dev@swift.org> wrote: > Okay, I'm getting it a little better. __FILE__ used to be in Swift, > now we're using #file. That macro was probably NOT supposed to be > expanding, but rather matching the actual symbol __FILE__ > > Still not sure how it changed to be expanding though. > > On Thu, Dec 29, 2016 at 10:58 AM, Micah Hainline > <micah.hainl...@gmail.com> wrote: > > I'm looking to spruce some of this up, now that I've taken the time to > > understand what people are using it for. I've broken it down locally > > to have all the macro functions that expanded KEYWORD directly go > > through an intermediary for consistency, and added a SWIFT_KEYWORD > > that expands to KEYWORD. No more defining SIL_KEYWORD first just to > > eliminate SIL from KEYWORD. > > > > While doing so, I added another macro EXPR_KEYWORD for everything that > > was under the comment "Expression keywords". That caused errors when I > > put that new macro around __FILE__, and that made me wonder why in the > > heck __FILE__ is included in the keywords. What I got when I did that > > was a token pasting error in the many places we make things like > > tok::kw_##KW. Suddenly it's token pasting to create > > kw_"/User/micah/swift/blah/blah/something.cpp" and failing. > > > > I'm sure I'm just not very good with macros and a long-term whiz at it > > would laugh, but I'm confused about what we're trying to do here. Why > > would we put __FILE__ into the keywords list to begin with? > > > > On Wed, Dec 28, 2016 at 5:10 PM, Jacob Bandes-Storch <jtban...@gmail.com> > wrote: > >> I am not the authority here, but based on what I've seen this sounds > good to > >> me. I was once discouraged from adding an #undef in client code because > >> Tokens.def does it already. Mentioning that behavior in the comments > >> certainly can't hurt. > >> > >> > >> On Wed, Dec 28, 2016 at 2:37 PM, Micah Hainline via swift-dev > >> <swift-dev@swift.org> wrote: > >>> > >>> I'm still wrapping my head around this, but we're doing some heavy > >>> macro programming in swift/Parse/Tokens.def. We define macros such as > >>> KEYWORD and then include the file, which allows different things to > >>> happen based on what macros we've defined beforehand. > >>> > >>> Because it's using macros, subsequent includes of Tokens.def will have > >>> those same old macros defined unless they are subsequently undefined. > >>> That is actually happening in the bottom of the Tokens.def now, but > >>> apparently that wasn't always the case and there is some leftover code > >>> floating around that tries to deal with it. Sometimes (see > >>> SyntaxModel.cpp lines 98-100) we then #undef the macro afterward, in > >>> effect manually cleaning up after ourselves. In Lexer.cpp line 546 we > >>> define KEYWORD just to redefine it to be empty on line 602 presumably > >>> to avoid the previous definition stepping on our toes in the next > >>> couple of lines. Of course, the include already cleaned that up. > >>> > >>> I think we should go through and try to be more consistent with this. > >>> Tokens.def should have a comment block explaining exactly which macros > >>> will be checked and just specifying they'll all be undefined > >>> afterward, and all include usages should get rid of empty defines and > >>> undefines. Does that make sense? > >>> _______________________________________________ > >>> swift-dev mailing list > >>> swift-dev@swift.org > >>> https://lists.swift.org/mailman/listinfo/swift-dev > >> > >> > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
