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

[Jacob Bandes-Storch]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161228/27d560c5/attachment.html>