[cfe-dev] improving modularize

[Thompson, John]

Hi,

For those working on modules (such as Doug) as well as those using or just interested in the modules effort underway, do you have some specific ideas for improving modularize?

I guess the main issue to do with coverage, that is, making sure that real or potential problems are detected and reported.  Related to that would be to improve the existing error messages and warnings, in order to help the user pinpoint and fix the problem areas.

Recently I used modularize to help prepare some of the headers (mostly C, with some C++) from one of our platforms for modules, and that has given me a couple of ideas for places to start.  These are mainly just general directions, and will need some digging into to figure what or if anything can be done:

1. I'm wondering if the messages like:  'note: 'sigvec' at 378:8 not always provided" could be more helpful in providing the file name, and perhaps even the associated conditional directives that fire differently.  Also, report it once.

2.  For the messages like: "'xxx' defined at both 'yyy' and 'zzz'", combine them into a single message for all instances.

3.  Catch "extern "C"" problems.  I had some problems where some "#include" directives were buried in some  "extern "C" { }" blocks in some files and not in others.  See if this could be detected.  It's generally a bad practice, irrespective of modules, isn't it?

Please pass along any ideas you have, as I'm taking a crack at working on adding some improvements to modularize.

On a related topic, I tried to write a little test case for #3 like this:

without_extern_c.h:

  void my_func(int a);

with_extern_c.h:

  extern "C" {
  void my_func(int a);
  }

extern_test.h:

  #include "with_extern_c.h"
  #include "without_extern_c.h"

  void test3()
  {
    my_func(1);
  }

modularize input 1:

  extern_test_c.h

modularize input 2:

  without_extern_c.h
  with_extern_c.h

This is a problem because of the different linkages, right?  It wasn't detected in modularize, perhaps because it's a C++ thing.

Thanks.

-John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130226/7c529bed/attachment.html>