[cfe-dev] Conflicting vs. redefined ModuleMacros

[Jordan Rose via cfe-dev]

Hi, Richard. Jordan's back with another annoying ModuleMacro question for Swift. Let's say I have these two modules:

module Conflicting {
  explicit module A { header "ConflictingA.h" }
  explicit module B { header "ConflictingB.h" }
}

module Redefined {
  module A { header "RedefinedA.h" }
  module B { header "RedefinedB.h" }
}

Both headers in 'Conflicting' define a macro CONFLICTING, but with different values; a client is only supposed to import one of them. 'Redefined' is a little different: RedefinedB.h includes RedefinedA.h before defining the new value, and the client is probably going to import the entire top-level module. Let's say RedefinedB.h is even polite enough to use #undef.*

* If these examples sound bad, well, I agree, but the former is what the OpenGL framework on macOS has been doing for years, and the latter is how Clang's limits.h deals with a system limits.h.

The question: using ModuleMacro, how can I distinguish these two cases while building a PCM?

The obvious correct Clang answer is "don't bother, visibility will handle everything when the modules get imported", but unfortunately that doesn't fly for Swift, because of this third example:

module CrossModuleRedefinedCore {
  header "CrossModuleRedefinedCore.h"
}
module CrossModuleRedefined {
  // imports CrossModuleRedefinedCore
  header "CrossModuleRedefined.h"
}

In Swift, I'm allowed to say `CrossModuleRedefinedCore.REDEFINED` to get the old value, and `CrossModuleRedefined.REDEFINED` to get the new value. I'm not hugely concerned about this use case if I can get the other two to work well, but I haven't given up on it yet.

Any ideas? I already tried looking at the overrides, but that seems like it's represented the same in both cases.

Thanks,
Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171006/255536e8/attachment.html>