<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jun 22, 2011, at 1:58 PM, Douglas Gregor wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>On Jun 20, 2011, at 10:50 AM, Fariborz Jahanian wrote:<br><br><blockquote type="cite">Author: fjahanian<br></blockquote><blockquote type="cite">Date: Mon Jun 20 12:50:03 2011<br></blockquote><blockquote type="cite">New Revision: 133450<br></blockquote><font class="Apple-style-span" color="#006312"><br></font>This is really unfortunate, because it's intended that a declaration's linkage is an invariant in the AST. We don't depend on weak vs. non-weak so much in semantic analysis, so it's not as damaging as changing internal vs. external linkage would be, but it still causes weird breakage. For example, note how lib/AST/ExprConstant.cpp's EvalPointerValueAsBool checks for weak imports: this routine will now return different results in different parts of the translation unit, if we end up trying to evaluate the address of a variable after the first declaration and then again after it's had weak_import attribute added to it.<br><br>I know we're mimicking GCC behavior here, but I think this is a GCC bug that we should not emulate. Instead, we should complain (via a warning) that an already-declared variable cannot be made a weak_import in a subsequent declaration, and drop the WeakImportAttr from the later declaration. The motivating Radar refers to "an obscure linker test", so it's unlikely that any real code will be affected (and the warning makes sure that there's no silent breakage). <br><br>What do you think?<br></div></blockquote><div><br></div>In r133654. Please read the comment in code and let me know what you think.</div><div><br></div><div>- Thanks, Fariborz</div><div><br><blockquote type="cite"><div><br><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div></blockquote></div><br></body></html>