<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 11, 2019 at 3:04 PM Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div>On Mar 11, 2019, at 2:09 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br class="m_-3886603148012731582Apple-interchange-newline"><div><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 11, 2019 at 2:01 PM Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">You'll see the sad resolution of this two commits further down. (I reverted this one, too). There was a header file with a function body that used the LLVM_DEBUG macro (which I believe fundamentally cannot work inside a non-textual header) </div></blockquote><div><br>Right - if it depends on its inclusion state to define DEBUG_TYPE that's not modular. I assume that's the case? Oh, it looks like it is the case, that DEBUG_TYPE is defined within this file, so I don't think there's a problem with using LLVM_DEBUG here? It's not intended to consume the value of DEBUG_TYPE from its inclusion context.<br></div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div>Oh, I had missed that it did define its own DEBUG_TYPE.</div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div><br>Perhaps that's invalid in a modular context if it's ever included somewhere that also defines DEBUG_TYPE? I'm not sure there.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">and inside of it it called a dump method, thus pulling the reference to the dump method into the link.</div></blockquote><div><br>Missed a step here - inside of what it called a dump function? & why was that a problem? It called a dump function unconditionally rather than only under the condition that the dump function is defined? I'm not sure how modules would make/break that.<br></div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div>Perhaps the LLVM_DEBUG macro is a red herring then and just the presence of the dump() function in the function body was enough to produce the dependency on the dump function. The linker error was that that dump() method was an undefined symbol while linking llvm-lto.</div></div></div></blockquote><div><br>I'm still not sure I follow how the modularity of this file would be related to this problem - can you explain it in further detail, to make sure we're fixing this in the right way/tracking any other bugs this might be indicative of?<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><br></div><div>-- adrian</div></div></div></blockquote></div></div>