[swift-dev] undefining macros after including Tokens.def

[Jacob Bandes-Storch]

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 at 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.hainline at 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 <jtbandes at 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 at 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 at swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-dev
> >>
> >>
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161229/80edcd80/attachment.html>