DDoc is an embarrassment
Adam D. Ruppe
destructionator at gmail.com
Tue Nov 17 01:13:30 UTC 2020
On Monday, 16 November 2020 at 22:36:08 UTC, H. S. Teoh wrote:
> Yes, this is the problem with implementing the doc generator in
> the compiler
>
> There is no easy fix, however.
adrdox doesn't suffer from this.
Though it as its bugs in static if and version presentation, it
*usually* manages to do the obvious thing, for example:
http://dpldocs.info/experimental-docs/arsd.simpledisplay.OpenGlShader.html
Just show the condition with the declaration (as you can see I
actually turn `version(x) {} else {}` into just `version(!x)`
since i think it is easier for human consumption here). The user
can figure it out (hopefully).
> What should the output be, for example, if the `/// ditto`'d
> symbols are both aggregates?
http://dpldocs.info/experimental-docs/test2.foo.html
Not that hard, I didn't even consider this case specifically and
it worked well enough!
What adrdox does is if it sees the ditto comment, it dittos the
*comment*, not the output. So it acts like you copy/pasted the
same comment text, but then reprocesses it for each decl
separately.
Then, knowing it was ditto'd, it marks the two symbols as
"related".
> Ouch. Yeah, ddoc is a completely separate subsystem in the
> compiler, and I can see how when new features are added, the
> ddoc implications would be neglected.
Funny how adrdox manages to keep up with these things, but ddoc -
despite (or perhaps BECAUSE of) being integrated in dmd doesn't.
More information about the Digitalmars-d
mailing list