For haddock-0.x, Cabal cpp's all the modules with -D__HADDOCK__ because
the old haddock cannot parse all sorts of things.

However for haddock-2.x it is important not to use -D__HADDOCK__ because
the hacks that people added for haddock-0.x would make haddock-2.x fail.
For example they'd simply omit entire declarations. While haddock-0.x
didn't really care and parsed and renamed in a sloppy way, haddoxk-2.x
is basically ghc and so if the module does not compile then it also
cannot be processed via haddock-2.x.

That's quite a presumption there. I can certainly write a module that compiles and produces documentation for Haddock but that is different when compiled into binary form. Even without this particular problem, I can see that being potentially useful.

The proper solution is to make haddock not fail when it encounters TH
code or whatever the original problem was. It can ignore it for now, it
just has to not fail.

That's certainly the ideal solution; however, it is not there right now.

I would be happy to work around it if I could, but I can't. As far as I can tell, I can't pass any flags to Haddock via the Cabal file. I would love to tell Hackage to run Haddock like so, "cabal haddock --haddock-option=--optghc=-D__HADDOCK__", but I don't know how.

This adventure has exposed a major problem with Cabal that I have run into several times. It supports a limited set of external tools (e.g. Haddock, Alex, Happy, etc.), but it supports them in a limited way. Primarily, it is not possible to pass options to these tools (at least) through the configure script.

Also, regarding transparency with Hackage: is it possible to determine exactly which tools (e.g. Haddock version) are being used on the server? I would like to see a list on the website of the exact operations that will be applied to my package once uploaded.

Regards,
Sean