[cfe-dev] Module Questions

[Manuel Klimek]

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...

Cheers,
/Manuel


On Mon, Jan 6, 2014 at 5:05 PM, Dean Sutherland <dsutherland at cert.org>wrote:

> New Year’s ping for this thread in general, now that folks are getting
> back to work.
>
> Dean
>
> On Dec 22, 2013, at 2: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.
> >
> > 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/20140107/6284578b/attachment.html>