GNOME Bugzilla – Bug 704090
XML named entity resolution should happen before reference resolution
Last modified: 2015-01-06 17:16:06 UTC
Suppose that I have a C# class MyList<T>. Then the following reference works and creates a link to the type in the resulting HTML documentation: A MyList<T> is returned which contains the whole caboodle. but the following doesn't: A MyList<T> is returned which contains the whole caboodle. because Doxygen thinks that I want to refer to MyList<T> instead of MyList<T>. Additional information: I see no way that fixing this would be a breaking change. Sure, it can break kludged code which uses entities instead of % to suppress link generation.
I think there is also a more readable/elegant solution to your problem: Use \tref{MyList,T} for the link reference and define this new command in the config file as follows: ALIASES = tref{2}="\1<\2>" Let me know if this works for you.
Seems like NOTABUG to me. Please reopen if this is not the case.
I think this should be re-opened. The C# XML input mode is a bit broken in this state - you shouldn't have to enter MyList<T> to make it work, since <T> on its own is invalid XML (since T isn't a valid tag, and if it was it'd need a </T>, and <> chars shouldn't appear in XML attributes such as cref="" anyway). The Microsoft format for cref uses {T} for generics instead of <T> to get around the XML issue, and it'd be really helpful if doxygen followed this same convention. I think you could fix this and make lots of users happy quite elegantly and safely by just replacing { with < and } with > when processing links (e.g. cref=). The proposed workaround isn't any good for those of us who already have lots of C# doc comments in XML format and can't easily convert to using \ref, or who need the comments to still be parseable by the Visual Studio tooling for this.
Good suggestion. I'll include support for this in the next GIT update.
This bug was previously marked ASSIGNED, which means it should be fixed in doxygen version 1.8.9. Please verify if this is indeed the case. Reopen the bug if you think it is not fixed and please include any additional information that you think can be relevant (preferrably in the form of a self-contained example).
Still some issues with links to generic classes, see https://bugzilla.gnome.org/show_bug.cgi?id=738167 (which this issue is basically a duplicate of)