<div dir="ltr">As I've said - we have done global code analysis for a while now, and I'm not sure what modules would help (apart from speed ups). If you want to restrict yourself to certain depths / components, I'd suggest to do this on a higher level. I don't think I have more insights, sorry...<div>
<br></div><div>Cheers,</div><div>/Manuel</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 6, 2014 at 5:05 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">New Year’s ping for this thread in general, now that folks are getting back to work.<br>
<span class="HOEnZb"><font color="#888888"><br>
Dean<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Dec 22, 2013, at 2:54 PM, Dean Sutherland <<a href="mailto:dsutherland@cert.org">dsutherland@cert.org</a>> wrote:<br>
<br>
> 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>
><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>
_______________________________________________<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>
</div></div></blockquote></div><br></div>