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