[Mono-docs-list] [Fwd: [Mono-dev] monodocer fails to import slashdoc in 1.1.18]

[Jonathan Pryor]

On Wed, 2006-10-18 at 08:33 -0400, Miguel de Icaza wrote:
> email message attachment, "Forwarded message - [Mono-dev] monodocer
> fails to import slashdoc in 1.1.18"
> > mono 1.1.18 adds generics support for monodocer. Unfortunately,
> > 'importslashdoc' seems to be broken: inline documentation extracted
> > by the mono compiler from the sources (/doc) is not merged with the
> > monodoc xml structure anymore; all fields are initialized with
> > 'To be added'.

I don't have a full test case for this yet, but I think things will be
broken for /doc-comments on generic members, as `gmcs /doc` support
seems to have the same generics support as monodoc before my patches
(read: hardly any).

For example, given the member:

	public void Process (Generic.MyList<int> list) {}

`gmcs /doc` "helpfully" generates:

	<member
name="M:Mono.DocTest.UseLists.Process(Mono.DocTest.Generic.MyList`1[[System.Int32, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]])">

It *should* generate:

	<member
name="M:Mono.DocTest.UseLists.Process(Mono.DocTest.MyList{System.Int32})">

(Or the above with tr/{}/<>/g.)

As long as gmcs generates such "bizarre" member IDs, I don't see any way
for `monodoc -importslashdoc` to support importing /doc-comments on
generic members.

(Furthermore, I get NullRefereceExceptions when trying to run
`gmcs /doc` when *real* generic types/members have doc comments on them.
I don't have a small test case yet.)

I'm still looking into why non-generic -importslashdoc usage is broken.
It seems to only be *partially* broken (even weirder) -- some members
get comments properly inserted, others don't.

 - Jon