Note that there is a regression for the example from #62. This might be OK, because an unqualified map should probably be flagged since it could come from std. Other workarounds include

1. Only warning if std:: is present. This goes against a previous decision to warn on unqualified names.
2. Only flag if a comma is present in the template for templates that require multiple template types. The implementation would be a little bit more complicated. If the type name is long, it might go to the next line.
3. Warn on unqualified map. Users would could use map qualified from other namespaces.

We shouldn't introduce a regression. Locally defined classes should not be IWYU'd.

Is there a preference on how we want to handle this? I'd like to have a simple check that is consistent. Right now the checks for set and map are customized. It would be great if they didn't need to be. For example, it's weird that those each have special rules, but unordered_set and unordered_map don't.

The current check for map prevents false positives from other map definitions by using a fully qualified name(i.e. std::map). This check goes against the comment from before.

The problem specifically with the name map is that it can mean applying a function to a functor. The provided example, could be used to initialize a functor, Foo.

template <typename T>
struct Foo {
    T t;
};
template <typename T>
Foo<T> map(T t) {
    return Foo<T>{ t };
}
struct Bar {
};
auto res = map<Bar>();

That example, only has one template; but it would be reasonable to have multiple ones. One could be the functor. The other could be a function.

If we want to go down the route of applying the check against 2+ template arguments, there are a couple of options.

1. Check for at least one comma in the same line. This check would be sensitive to formatting and nested types.
2. Check for at least one comma across multiple lines. This check would be robust to formatting, but not nested types.
3. Parse the angle brackets across multiple lines at the appropriate level. This would be robust to formatting and nested types.

Another set of options would be to look for a declaration with the same name in the same file. If the declaration is present, the check would be ignored. That might be difficult due to the most vexing parse. Also, it would miss declarations in other files.

It seems like all the options have trade offs, but it would be good to have some clarity.

I made a change such that map still requires that the name to be fully qualified. The comment looked wrong so I updated it. There isn't a regression, but auto foo = map<int, int>(); won't warn.

oops, forgot the changelog part...

Anyways, you don't need to force push here. We always squash on merge.