<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 25, 2013, at 6:49 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">On Fri, Oct 25, 2013 at 6:20 PM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:akyrtzi@gmail.com" target="_blank">akyrtzi@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div class="h5">
<div>On Oct 25, 2013, at 5:33 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">On Fri, Oct 25, 2013 at 4:54 PM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:akyrtzi@gmail.com" target="_blank">akyrtzi@gmail.com</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div>
On Oct 25, 2013, at 4:35 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">On Fri, Oct 25, 2013 at 4:25 PM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:akyrtzi@gmail.com" target="_blank">akyrtzi@gmail.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div style="word-wrap:break-word"><div><div>On Oct 25, 2013, at 2:44 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">On Tue, Mar 26, 2013 at 6:25 PM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:akyrtzi@gmail.com" target="_blank">akyrtzi@gmail.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Author: akirtzidis<br>
Date: Tue Mar 26 20:25:19 2013<br>
New Revision: 178105<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=178105&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=178105&view=rev</a><br>
Log:<br>
[modules] Re-enable the "ambiguous expansion of macro" warning.<br>
<br>
Also update "test/Modules/macros.c" to test modified semantics:<br>
-When there is an ambiguous macro, expand using the latest introduced version, not the first one.<br>
-#undefs in submodules cause the macro to not be exported by that submodule, it doesn't cause<br>
undefining of macros in the translation unit that imported that submodule.<br>
This reduces macro namespace interference across modules.<br>
<br>
Modified:<br>
cfe/trunk/lib/Lex/PPMacroExpansion.cpp<br>
cfe/trunk/test/Modules/macros.c<br>
<br>
Modified: cfe/trunk/lib/Lex/PPMacroExpansion.cpp<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/PPMacroExpansion.cpp?rev=178105&r1=178104&r2=178105&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/PPMacroExpansion.cpp?rev=178105&r1=178104&r2=178105&view=diff</a><br>
==============================================================================<br>
--- cfe/trunk/lib/Lex/PPMacroExpansion.cpp (original)<br>
+++ cfe/trunk/lib/Lex/PPMacroExpansion.cpp Tue Mar 26 20:25:19 2013<br>
@@ -211,7 +211,9 @@ bool Preprocessor::isNextPPTokenLParen()<br>
/// expanded as a macro, handle it and return the next token as 'Identifier'.<br>
bool Preprocessor::HandleMacroExpandedIdentifier(Token &Identifier,<br>
MacroDirective *MD) {<br>
- MacroInfo *MI = MD->getMacroInfo();<br>
+ MacroDirective::DefInfo Def = MD->getDefinition();<br>
+ assert(Def.isValid());<br>
+ MacroInfo *MI = Def.getMacroInfo();<br>
<br>
// If this is a macro expansion in the "#if !defined(x)" line for the file,<br>
// then the macro could expand to different things in other contexts, we need<br>
@@ -286,25 +288,22 @@ bool Preprocessor::HandleMacroExpandedId<br>
}<br>
}<br>
<br>
- // FIXME: Temporarily disable this warning that is currently bogus with a PCH<br>
- // that redefined a macro without undef'ing it first (test/PCH/macro-redef.c).<br>
-#if 0<br>
// If the macro definition is ambiguous, complain.<br>
- if (MI->isAmbiguous()) {<br>
+ if (Def.getDirective()->isAmbiguous()) {<br>
Diag(Identifier, diag::warn_pp_ambiguous_macro)<br>
<< Identifier.getIdentifierInfo();<br>
Diag(MI->getDefinitionLoc(), diag::note_pp_ambiguous_macro_chosen)<br>
<< Identifier.getIdentifierInfo();<br>
- for (MacroInfo *PrevMI = MI->getPreviousDefinition();<br>
- PrevMI && PrevMI->isDefined();<br>
- PrevMI = PrevMI->getPreviousDefinition()) {<br>
- if (PrevMI->isAmbiguous()) {<br>
- Diag(PrevMI->getDefinitionLoc(), diag::note_pp_ambiguous_macro_other)<br>
+ for (MacroDirective::DefInfo PrevDef = Def.getPreviousDefinition();<br>
+ PrevDef && !PrevDef.isUndefined();<br>
+ PrevDef = PrevDef.getPreviousDefinition()) {<br>
+ if (PrevDef.getDirective()->isAmbiguous()) {<br>
+ Diag(PrevDef.getMacroInfo()->getDefinitionLoc(),<br>
+ diag::note_pp_ambiguous_macro_other)<br>
<< Identifier.getIdentifierInfo();<br>
}<br>
}<br>
}<br>
-#endif<br>
<br>
// If we started lexing a macro, enter the macro expansion body.<br>
<br>
<br>
Modified: cfe/trunk/test/Modules/macros.c<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/macros.c?rev=178105&r1=178104&r2=178105&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/macros.c?rev=178105&r1=178104&r2=178105&view=diff</a><br>
==============================================================================<br>
--- cfe/trunk/test/Modules/macros.c (original)<br>
+++ cfe/trunk/test/Modules/macros.c Tue Mar 26 20:25:19 2013<br>
@@ -1,4 +1,3 @@<br>
-// XFAIL: *<br>
// RUN: rm -rf %t<br>
// RUN: %clang_cc1 -fmodules -x objective-c -emit-module -fmodules-cache-path=%t -fmodule-name=macros_top %S/Inputs/module.map<br>
// RUN: %clang_cc1 -fmodules -x objective-c -emit-module -fmodules-cache-path=%t -fmodule-name=macros_left %S/Inputs/module.map<br>
@@ -10,12 +9,12 @@<br>
// These notes come from headers in modules, and are bogus.<br>
<br>
// FIXME: expected-note{{previous definition is here}}<br>
+// FIXME: expected-note{{previous definition is here}} expected-note{{expanding this definition of 'LEFT_RIGHT_DIFFERENT'}}<br>
+// expected-note{{other definition of 'TOP_RIGHT_REDEF'}} expected-note{{expanding this definition of 'LEFT_RIGHT_DIFFERENT2'}}<br>
// expected-note{{other definition of 'LEFT_RIGHT_DIFFERENT'}}<br>
-// expected-note{{expanding this definition of 'TOP_RIGHT_REDEF'}}<br>
-// FIXME: expected-note{{previous definition is here}} \<br>
-// expected-note{{expanding this definition of 'LEFT_RIGHT_DIFFERENT'}}<br>
<br>
-// expected-note{{other definition of 'TOP_RIGHT_REDEF'}}<br>
+<br>
+// expected-note{{expanding this definition of 'TOP_RIGHT_REDEF'}}<br>
<br>
@import macros;<br>
<br>
@@ -80,8 +79,8 @@ void f() {<br>
# error TOP should be visible<br>
#endif<br>
<br>
-#ifdef TOP_LEFT_UNDEF<br>
-# error TOP_LEFT_UNDEF should not be visible<br>
+#ifndef TOP_LEFT_UNDEF<br>
+# error TOP_LEFT_UNDEF should still be defined<br></blockquote><div><br></div><div>This seems completely broken to me, and it breaks libc++.</div><div><br></div><div>glibc has something like:</div><div><br></div><div> // stdio.h<br>
</div><div> int getc(FILE*);</div><div> #define foo_getc(x) /* ... */</div><div> #define getc(x) foo_getc(x)<br></div><div><br></div><div>libc++ has:</div><div><br></div><div> // cstdio</div><div> #include <stdio.h></div>
<div><br></div><div> #ifdef getc</div><div> #undef getc<br></div><div> #endif<br></div><div><br></div><div> namespace std { using ::getc; }</div><div><br></div><div>This results in any program which includes <cstdio> being unable to use std::getc:</div>
<div><br></div><div> // main.cc</div><div> #include <cstdio></div><div> int k = std::getc(stdin); // error, no foo_getc in namespace std</div><div><br></div><div>Can you explain a bit about the effect you were trying to achieve here? Here's another case:</div>
<div><br></div><div><div> #include <stdio.h></div><div> #include <something></div><div> int k = getc(stdin); // still uses the macro from <stdio.h></div></div><div><br></div><div>I think we might want to ignore an #undef in <something> if <something> comes from a module that doesn't depend on the module containing <stdio.h>. (If it's just using the macro for its own internal purposes, or more generally if rearranging the order in which we chose to load the modules would result in a consistent macro definition chain.)</div>
<div><br></div><div>I think the behavior we want here is:</div><div><br></div><div>* If a module M1 depends on a module M2, macro definitions/undefs in M1 and M2 are never ambiguous (M1 is always ordered after M2).</div>
<div>
* If there are multiple ambiguous 'most recent' definitions of a macro (excluding chains that end in an undef), and the macro is used, warn.</div><div><br></div><div>Put another way: consider the subgraph of the imported portion of the module dependency graph in which the macro is or was defined. All roots of that subgraph for which the macro is defined must define it to the same value, or we warn on ambiguity. If there are any such roots, the value of the macro is the value at such a root. Otherwise, the macro is not defined.</div>
<div><br></div><div>Does that sound right to you?</div></div></div></div></blockquote><div><br></div></div><div>I agree that for</div><div><br></div><div><span style="white-space:pre-wrap"> </span>@import cstdio</div>
<div><br></div><div>'cstdio' should be able to "not export" the 'getc' macro. </div><div>Without some language support to explicitly state whether you are undef'ing to avoid exporting vs undef'ing for internal use, I think it's reasonable to choose the former as default (undef'ing to avoid exporting).</div>
<div><br></div><div>I'm not so sure about M1 just disabling macros from M2, even when I have explicitly imported M2. I don't like that a module may affect another module import in a surprising way; for example:</div>
</div></blockquote><div><br></div><div>In my suggestion, this would only happen if both:</div><div> 1) M1 depends on M2, so it's undefining the macro defined by M2 not some other macro that happens to have the same name, and</div>
<div> 2) The undef of the macro is visible (you imported it into this TU).</div></div></div></div></blockquote><div><br></div></div><div>I imported M2 to use its macro; I also imported M1 to use some other symbol from it. It should not be my concern that M1 wants to undef the macro that I want to import, if I don't want to see the macro from M2 I will remove its import declaration.</div>
</div></div></blockquote><div><br></div><div>Who says you imported M2?</div></div></div></div></blockquote><div><br></div></div></div><div>I'm not sure what writing "@import M2" explicitly means, if not that I imported M2 ?</div>
</div></div></blockquote><div><br></div><div>In your case 1:</div><div><br></div><div>@import M1 // this re-exports M2 and re-purposes BAZOO; I can use symbols from both as M1 intended<br></div><div><br></div><div>The comment is false. You cannot use the symbol BAZOO from M1, because the BAZOO macro from M2 tramples on it.</div></div></div></div></blockquote><div><br></div><div>Yes, I agreed this is wrong and needs fixing; I was probably unclear here.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div style="word-wrap:break-word"><div class="im">
<blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>If you didn't import M2, you don't want its macros leaking out of M1, especially since M1 explicitly tried to remove them.</div>
<div><br></div><div>If you imported both of them, then the effect of importing M1 and M2 is that you don't get the macro. M1 gets to decide this, because it is higher up in the layering. This is exactly what would happen with header files.</div>
</div></div></div></blockquote><div><br></div></div><div>You can do some horrible things with header files, I don't find "this is exactly what would happen with header files" a strong argument; modules are supposed to be more resilient and self-contained when combined together.</div>
</div></blockquote><div><br></div><div>Modules are also supposed to provide a smooth upgrade path from headers.</div></div></div></div></blockquote><div><br></div><div>That is true; but modules is also a chance to reconsider the horrible tricks that headers use and at least <i>try</i> first if there's an alternative way other than "crippling" the module design in order to accommodate some horrible headers.</div><div>Basically, making the module semantics worse in order to accommodate a horrible header should be a conscious/informed choice.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
<div style="word-wrap:break-word"><div class="im"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div style="word-wrap:break-word"><div><blockquote type="cite">
<div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote">I don't think this applies to the situations you want to block; I think my proposal gives you want you want there.</div></div></div></blockquote><div><br></div></div><div>How am I going to be able to use the macro from M2 while still importing M1 ?</div>
</div></blockquote><div><br></div><div>Why would you want to? M1 is removing that macro for a reason. I've given you a concrete example of a case where what I'm proposing is the right thing; </div></div></div></div>
</blockquote><div><br></div></div><div>I agreed that "@import cstdio" should not export the 'getc' macro</div><div class="im"><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>I'd like to see an example of a case where what you're proposing is the right thing. No-one I've spoken to thinks it makes sense, but perhaps we're missing something here.</div></div></div></div></blockquote>
<blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>If you want this effect, use the macro from M2 before you import M1, or in a different TU. Same as with header files.</div></div></div></div></blockquote><div><br></div></div><div>With your suggestion my issue is that I cannot access the macros that M2 exports, irrespective of whether or not I imported another module; your workaround is that I should restructure my code.</div>
</div></blockquote><div><br></div><div>We have a single global namespace for macro names. If there are macro definition conflicts between modules, we're going to have problems. In the case I care about, there *is* no conflict, but we break the program anyway. That doesn't seem good.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>With my suggestion your issue is that the macro from M2 affects a symbol with the same name from M1; my workaround is that you simply remove the import of M1 and import only M2 (as the author of M2 intended).</div>
</div></blockquote><div><br></div><div>I don't understand what you're saying here. I want to use the interface provided by M1. If I've not imported M2, I may not *care* about the interface of M2, except that M1 happens to re-export it with the macros changed to functions (as a user of M1, I may not even know that M2 *exists*). I don't see why that shouldn't work naturally.</div></div></div></div></blockquote><div><br></div><div>As I said above, I think there's a misunderstanding here; to reiterate: when you say "I want to use the interface provided by M1. If I've not imported M2" this is case 1) I mentioned and I agree with what you said should happen. If this does not happen currently then it should be fixed.</div><div><br></div><div>Should we focus on what should happen when importing <u>both</u> M1 and M2 ?</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>I should add: I don't care what happens with @import, just with a #include that is promoted to a module import (that is, the backwards-compatibility path).</div><div><br></div><div>We can imagine #undef X as a pseudo-definition of X as "not a macro", and that absence-of-a-macro might be part of a module's interface (as it is for the C++ standard library). From that perspective:<br>
</div><div> * if I import two *unrelated* modules, and one of them #undef's X and the other #defines it to something, I have a conflict that I should diagnose on a use of the macro</div><div> * if I import two *related* modules, and one of them *replaces* the other one's definition, the later (higher in dependency graph) module's definition should win</div></div></div></div></blockquote><div><br></div><div>How do I know that two modules are *related* ? One module may have imported the other but if it doesn't re-export it it might as well be an *unrelated* one from my perspective; why do I need to care what modules it imported internally ?</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>You've not yet given any concrete examples of why our current behavior is right. I'd like to see such an example to understand why the approaches I've suggested are not applicable.</div><div>
<br></div><div>In particular, you seem to be suggesting that if I have two related modules, and one of them deliberately replaces the other one's definition, then we have an ambiguity *unless* one of them happened to undefine the macro, in which case we silently ignore that undefine. I can't see how that's the right answer.</div>
</div></div></div>
</blockquote></div><div><br></div><div>I'm suggesting that If I explicitly import 2 modules, and the modules' interfaces disagree on what an identifier means, then there is ambiguity.</div><div>One module may or may not have imported the other module internally, but that doesn't change the fact that the modules' interfaces disagree on the meaning of an identifier.</div>There is a question of how to resolve this but at least a warning is warranted.</body></html>