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