Auto detecting Clang modules

[wilsonk]

Hello Elie,

After the 'Auto-detect Clang module map files and add module maps for libc and POSIX standard headers' push today, most of the examples in the libstdc++ directory don't work? Is there something missing from that push? Or should the command line be different now or something?

The errors are similar to this (some are missing ptrdiff_t also):
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/ext/new_allocator.h(61): Error: undefined identifier 'size_t'

Paradoxically the iterator example actually parsed, when it never worked before :)

I also saw the Qt5 demo and tried it here but it gives me a few errors like this:
Error: struct cpp..div_t conflicts with static import cpp..div_t at /usr/include/stdlib.h(97)
and then a template specialization error, just in case you aren't seeing the same thing.

Thanks,
Kelly

[Syniurge]

Oops I tested with the module map files in /usr/include and /usr/include/XXX/sys but not without. That's strange though, I don't see how the change could affect size_t.

Pushing the Qt5 example was a mistake, it's too early and I wanted to keep the surprise :) . To get rid of the name conflicts you need to place the module maps alongside the libc headers (and posix-sys.modulemap in e.g /usr/include/x86_64-linux-gnu/sys). And also generate module maps for QtCore, QtWidgets and QtGui which I haven't pushed yet. Now the map files are automatically loaded just after loading the PCH, Calypso looks for every .modulemap file (unlike Clang which only check module.modulemap) in all the directories known to clang::SourceManager.

But there are further errors once the name clashes are fixed, there's the same issue that affected MSVC libs but I identified the cause. Later today I'll backport a fix from DMD 2.067 (I can't fix these issues right now, working exceptionally today).

[Syniurge]

I failed to reproduce your error, vector, string, deque, bitset and map are working for me without the .modulemap files.

[wilsonk]

Haha, well this is interesting. I actually had a modulemap file in /usr/include already and that is what was causing the problem!

I was messing around with speeding up a different library using modules and clang, which worked, but I didn't remove the modulemap file afterwards.

So at least food for thought that we might have to be more specific about which modulemaps to import...I suppose???

Thanks,
Kelly

[wilsonk]

Well, two steps forward one step back with module maps it looks like. The examples in the libstdc++ directory seem to be the same as before these changes but Dlib is much worse off now.

Several headers used to modmap just fine, but now most don't with the modulemap files in /usr/include (and sys)...seeing things like this:

/home/wilsonk/Downloads/dlib-18.12/dlib/timer/../map.h(25): Error: module cpp.dlib.map template identifier 'map' is not a member of 'module map'

Just thought I would mention it so this issue doesn't get closed, and in case you aren't seeing it. I am not sure if you are even testing Dlib :)

Thanks,
Kelly

[Syniurge]

Yes well the step back is because the namespaces inside Clang module headers aren't mapped as I learned today too (oversight + what would be the D equivalent?). I'm working on a change of rules for Clang modules that should set things right.

That won't be how Clang modules were supposed to work anymore so the extension will be renamed to .modulemap_d to differentiate them from normal Clang maps.

[wilsonk]

Hello Elie,

Ah, ok. Sounds good. I like the modulemap_d idea, for sure.

Thanks,

Kelly

From: Elie Morisse [mailto:[email protected]]
Sent: Sunday, April 26, 2015 6:42 PM
To: Syniurge/Calypso
Cc: wilsonk
Subject: Re: [Calypso] Auto detecting Clang modules (#15)

Yes the step back is because the namespaces inside Clang module headers aren't mapped as I learned today too (oversight + what would be the D equivalent?). I'm working on a change of rules for Clang modules that should set things right.

That won't be how Clang modules were supposed to work anymore so the extension will be renamed to .modulemap_d to differentiate them from normal Clang maps.

—
Reply to this email directly or view it on GitHub #15 (comment) .

[wilsonk]

It looks like the auto detecting is working and has gotten us back to where we were with all of the example libs I tested last week (a couple improvements actually, but then I run into other errors).

I thought I would mention here that I had an interesting error with libzmq. I made a modulemap file for libzmq/include/zmq.h in my home directory and put it in /usr/include, but I had forgotten that I had installed a different version of zmq via apt-get and therefore was getting some errors.

Unfortunately the errors were non-descriptive and just said Calypso couldn't find 'zmq_socket', etc. It turns out that the number of parameters to that function had changed between versions, but the name was the same so I kept looking at the files in my home dir and wondering why they couldn't be imported properly.

Once I removed the old version of zmq the modulemap file worked fine and I could import the functions in zmq.h.

Thanks,
Kelly

[Syniurge]

Hmm strange I'm also encountering the problem now, only the first declaration of a header gets mapped and I have no idea why. For libc headers everything was mapped because for each header every decl is inside extern "C" {} (clang::LinkageSpec). It also works if they're in a namespace for the same reason.

The qualified names built by typeQualifiedFor are correct, which means that cpptypes.cpp knows which header a decl is from. But something goes wrong in mapClangModule(), RegionDecls always has a single decl (or zero if the first decl is a named tag).

Investigating..

[Syniurge]

Oops this is a different issue from before, nevermind.