Looks obviously correct to me. Ship it! :-)

I opted not to fix this in my earlier PRs until I figured out how this was trying to hook into the implementation-defined index - which is coming up shortly on my personal todo list.

The subitem should be just what, not bad_cast::what / bad_exception::what. As written, this is the index entry for bad_cast::bad_cast::what. We seem to get this wrong for all the what members and nothing else...

@zygoloid: True, but at least this PR makes it a bit more consistent. Removing the inner qualification would seem apposite, though.

Looks like it's not only the what members; we also get this wrong for ios_base::failure, ios_base::Init, and type_info::name.

Are you thinking that all members, whether they're functions or types, should just have an unqualified index entry nested under their containing class? I guess for ios_base::* we could just remove the "constructor", "destructor" entries and only have the item itself.

I've made some cleanups in 6d3936c.

The approach I took is that class member, irrespective of type, should be listed under the name of its class (the qualified name if it's a nested class)

So we have an Init and a failure under ios_base, but the members of those types are listed under separate top-level ios_base::Init and ios_base::failure index entries:

I'm not sure whether we can do better than this, thoughts appreciated.

Part of the point of the library index is to indicate which names are reserved (that is, names the program can't #define before including a library header), so each name that's used should also be listed as a top-level entry; this means we'd end up with all of "failure, ios_base", "ios_base, failure", and "ios_base::failure" in the index. I'm in two minds as to whether that's excessive.

I'm thinking "excessive"...

That said, maybe the nested entries like "ios_base, failure" should say "see: ios_base::failure".

That said, we do have an index entry for what, so perhaps we also should have one for failure.

what is a virtual function defined for many classes, while failure is a nested class with its own members. The nesting in the index indicates something quite different in these cases (and is common throughout the index).

I think that Richard has the right shape above - that I what I was trying to achieve in my recent clean-up of the constructors when I fell into this hole. The additional unqualified entries sound excessive to me, but then, I don't use the index as a means to find the reserved library names, so excessive may be the right answer - in which case I like Thomas 'see xxx' solution.

I've made some cleanups in 6d3936c.

Even better.