[cfe-dev] Module Questions

[Manuel Klimek]

On Sun, Dec 22, 2013 at 8:54 PM, Dean Sutherland <dsutherland at cert.org>wrote:

> Doug (and others):
>
> I'm working on static analysis of C and C++ code, and need a mechanism for
> processing groups of TUs that have both:
> * a known and statically complete interface (dynamic dispatch & function
> pointers are a different problem that need not be considered here)
> * known and statically enumerable contents.
>
> These properties would enable interesting cross-TU analyses, including
> some forms of sound inference across TUs.
>

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 ;)


>
> Reading through the various Modules information I've found (e.g.,
> http://clang.llvm.org/docs/Modules.html 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.
>
> 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).
>
> 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)?
>
> 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.
>
> Dean Sutherland
> dsutherland at cert.org
>
> 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.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131223/c2da3757/attachment.html>