[cfe-dev] Module progress?

[Douglas Gregor]

On Jan 22, 2013, at 4:14 AM, Thomas Young <thomasyoung at free.fr> wrote:

> > > How can we help?
> >
> > Modules is a big feature, and there are a few places where one could help. Some ideas:
> 
> The diagnostics, fix-its and tracking unused imports points really seem like they would just be icing on the cake.

They are, but (1) icing is an important part of this feature and an important aspect of Clang, and (2) working on the core modules implementation in Clang requires very deep knowledge of Clang's ASTs and invariants, so it's not really the best way to help the modules effort unless you have that deep knowledge.

> Speaking for myself, for diagnostics and fixits at least, I'd be very happy for something that works in the case where there are no errors, (in the sense that in finishes compilation and generates the desired object file result), but falls back to the 'traditional' compilation model in case of errors (so with diagnostics and fixits then being generated as necessary by existing code for this).
> 
> (I find that most of the time spent compiling is for compilation without errors. When changing stuff that can introduce errors I tend to be working with just one object file, or unit test, directly, and then compilation times are much less of an issue.)

As noted in my other reply, I don't think this is feasible.

> >  - Improve the 'modularize' tool I hacked up (sources attached), which attempts to find non-modular behavior in a set of header files.
> 
> Right, this kind of tooling definitely seems like it can be quite important. (Although I'd still be very happy to see modules working without this feature!)
> 
> As a first step, I guess it could be nice to have some kind of feedback to tell us at least where we violated the modular header assumptions/constraints. Perhaps one way to do this could then be to have an extra compile mode that performs both traditional and modular compilation in parallel, and tells you as soon as these diverge? (at whatever level of granularity, e.g. with checks after each module import would be fine to start with).


I don't think an extra mode is the right approach here, because you can't really build with modules until you have module maps, so there's nothing to compare to. Plus, comparing modules build to a non-modules build implies that one knows how to trigger modules-related failures in the compiler and then explain those failures to the user. It's far more direct to take the route "modularize" does of identifying common problems so that people can fix their headers. But it needs a lot of work, and should (ideally) also be able to help the user write a good module map for those headers.

	- Doug