Regex on symbol names doesn't seem to quite work

[ThosRTanner]

Given this:

QDir

#include "qdir.h"

qdir.h

class QDir { public: class Filters { }; };

test.cc

#include <QDir>

void test() { QDir::Filters f; }

And this mapping file:

[
    { symbol: [ "QDir", "private", "<QDir>", "public" ]},
    { symbol: [ "@QDir::.*", "private", "<QDir>", "public" ]},
]

I get told I should add #include "qdir.h" for QDir::Filters. I've tried pretty much everything, and the only way I can get it to behave is to specify the full name rather than using a regex in the second mapping entry. (I was hoping to have one entry, @qdir(::.*)?

[kimgr]

Regexes aren't supposed to work for symbols. I guess it could be made to work, but that would mean you'd have to keep a map from regex -> target symbol, and evaluate every symbol against every key in that map, which seems pretty costly.

There's some specialized handling of regexes for include mappings, but I don't know the details there. It looks like they're expanded to all matching headers before IWYU analysis begins.

[ThosRTanner]

the documentation says:

Like include, symbol directives support the @-prefixed regex syntax in the first entry. 

(from https://code.google.com/p/include-what-you-use/wiki/IWYUMappings)

And it'd be nice if it did work, because following header files for QT is a nightmare (QList::toSet ends you up in qset.h, which may be sensible, but it's not what the documentation says!) So you end up with an awful lot of symbol mappings anyway.

[ThosRTanner]

Thinking about that it strikes me as likely that subclasses of classes would be in the same header. That is to say that for any class Class, class Class::SubClass will actually be defined in the same header. It more or less has to be. So you wouldn't really need a regexp.

[kevinoid]

I just encountered this issue as well. Regex symbol matching would be nice, but unless that is coming soon it would be very helpful to fix the incorrect documentation in docs/IWYUMappings.md.

[purpleKarrot]

I agree with @ThosRTanner that proper handling of nested types makes all our use cases of regex symbol mappings disappear. I created #451. I think this issue can be closed.

Note that it is possible to forward declare nested types:

struct Foo
{
  struct Bar;
};

And then defining the type in a different header:

struct Foo::Bar
{
};

So, the symbols Foo::Bar and Foo are not guaranteed to be defined in the same header.

But: if there is a mapping for Foo and no mapping for Foo::Bar, it is safe to assume that Foo::Bar should follow the mapping for Foo.

[kimgr]

@ThosRTanner, if you agree, can you close this issue? Thanks.