Bug 12594 – Follow anchor naming standards in generated html when parsing templates.

Created attachment 1346 Generated html from standard class and template class. When generating html using ddoc from standard classes or structs etc. the anchors referring to methods inside the html look like this: <a name="Foo.bar"></a> Where Foo is the class and bar is the method. So anchor names reflect the hierarchy of the nested elements. Another example is if you have nested static structs the generated anchors look like this: <a name="CommandArgs.Event.button"></a> Where CommandArgs is the outer struct, Event is a nested static struct and button is an element of Event. With anchors named like this, creating indexes from generated ddoc html is a breeze. The problem is that when an element is a template of some sort this standard is not followed. For example, if the above class example was generated from a templated class the anchor for the bar method would look like this instead: <a name="bar"></a> Which is missing the parent. See the attachment. This enhancement is to request all anchors in all generated html follow the same standard of including the nesting information in the name of the anchors.

Internal note: From a quick glance it looks like 'parent' is not set for a non-instantiated template member, which probably makes sense if semantic() was not run on the template. So the call to 'emitAnchorName' won't do much since parent will be NULL. I've ran into a similar problem while fixing Issue 648. I think we should consider implementing a separate ddocSemantic() routine, which will do a minimal amount of semantic analysis just in order to initialize the fields required for proper ddoc output. If you look at my fix for Issue 648 (https://github.com/D-Programming-Language/dmd/pull/1485/files) you'll see I'm running a semantic pass, but since I only need minimal information for ddoc to work it would be less expensive to have a separate and minimal ddocSemantic() routine instead. Any thoughts from other devs?

*** This issue has been marked as a duplicate of issue 10366 ***