<div dir="ltr"><div dir="ltr">On Mon, Jun 28, 2021 at 1:44 PM Shoaib Meenai via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_-346484819629276730WordSection1">
<p class="MsoNormal"><span style="font-size:11pt">We have a remote build system that uses content-addressed storage, in which all files with the same content are hard linked. I noticed that our output object files differed when they were compiled locally
vs. remotely, and it turns out that #pragma once considers hard links to be identical, regardless of their path. Our local builds don’t have the hard linking but our remote builds do, so the include tree is different between local and remote builds (because
of the #pragma once behavior difference), which causes debug info to differ.</span></p></div></div></blockquote><div><br></div><div>I have heard of such things in theory, but this is the most explicitly real-world-ish example I've seen yet. :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-346484819629276730WordSection1">
<p class="MsoNormal"><span style="font-size:11pt">Is this behavior desirable? You can construct a convoluted example that works when you copy a file and fails when you hard link it:</span></p></div></div></blockquote><div><br></div><div>Yes, that makes sense to me. "#pragma once" means roughly "Process <b><i>this file</i></b> just once, even if you see <i><b>this file</b></i> being included multiple times." Obviously if you take this file and <i><b>copy</b></i> it, then you have two files: namely, <i><b>this file</b></i>, and the copy you just made of it. Whereas, if you don't copy the file, then there's only one file: <i><b>this file</b></i>.</div><div>So Clang's behavior here seems teachable.</div><div><span style="font-size:11pt"> </span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-346484819629276730WordSection1">
<p class="MsoNormal"><span style="font-size:11pt">gcc behaves the same as clang in this case, for what it’s worth.</span></p></div></div></blockquote><div><br></div><div>That's a very good pragmatic reason to keep Clang's behavior the same. It is kind of surprising that your "evil.h" example changes behavior depending on whether you hardlink-or-symlink the <i><b>one</b></i> header file, or copy it so that there are <i><b>two</b></i> header files. However, it would be vastly, vastly worse if your "evil.h" example changed behavior depending merely on which compiler you used to compile it!</div><div>So Clang's behavior here seems good for the ecosystem.</div><div><br></div><div>my $.02,</div><div>Arthur</div></div></div>