<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Dec 22, 2013 at 8:54 PM, Dean Sutherland <span dir="ltr"><<a href="mailto:dsutherland@cert.org" target="_blank">dsutherland@cert.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Doug (and others):<br>
<br>
I'm working on static analysis of C and C++ code, and need a mechanism for processing groups of TUs that have both:<br>
* a known and statically complete interface (dynamic dispatch & function pointers are a different problem that need not be considered here)<br>
* known and statically enumerable contents.<br>
<br>
These properties would enable interesting cross-TU analyses, including some forms of sound inference across TUs.<br></blockquote><div><br></div><div>Just curious: what part of your cross-TU analysis is blocked on this? We've been doing some forms of cross-TU static analysis without modules without any problems (apart from parsing time, obviously ;)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Reading through the various Modules information I've found (e.g.,<a href="http://clang.llvm.org/docs/Modules.html" target="_blank">http://clang.llvm.org/docs/Modules.html</a> etc.), I see that Modules appear to provide about 90% of what I'm looking for. Specifically, there appears to be a map between modules and the headers that comprise their interfaces. By extension, this map also seems to identify some header files that are excluded from the interface of a module.<br>

<br>
What I haven’t seen is a map between modules and the TUs that implement them.  For my purposes, such a map would indicate (a) for a given TU, which module (or modules) it is part of (if any), or (b) for a given module, which TUs provide its implementation. In principle, one could build the entire mapping between TUs & modules given a complete set of either of (a) or (b).<br>

<br>
Does such a map exist? Have I just failed to spot it? If not, would something along these lines be an interesting new capability (opt-in only, of course)?<br>
<br>
In addition, would it make sense to allow a TU to claim that it is part of the implementation of a module, perhaps via an attribute in the source code? Such a claim could be useful for static analysis even if it were totally ignored by the rest of the compiler and build system.  Indeed, I'd expect such an attribute would indeed be ignored by the rest of the system for the foreseeable future.<br>

<br>
Dean Sutherland<br>
<a href="mailto:dsutherland@cert.org">dsutherland@cert.org</a><br>
<br>
P.S.  Doug — we spoke briefly about this at the LLVM Dev conference in November. This is the first of several long-delayed follow-up messages.<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div></div>