In some cases Doxygen xml output does not provide accurate classification
of the various C-types, thus preventing the full documentation x-referencing.
Give some hints to the Doxy/RST bridge.

It is confusing when the codepath for the production doc build
involves calling functions with names like "test".  Rename things
which are in active use so that routines which are actually only
used for testing are more discernable as such.

ticket: 7505 (new)
tags: pullup
target_version: 1.11

Don't print out every node processed (or not processed) in the
doxygen-Sphinx bridge, nor print out a summary of how many types
or functions were processed.

While here, tell doxygen to be quiet in its output as well, and
not print out each file that is generated.  It still outputs
warnings, though.

ticket: 7495 (new)
tags: pullup
target_version: 1.11

The macro KRB5_KEYUSAGE_PA_REFERRAL was defined in an early revision
of draft-ietf-krb-wg-kerberos-referrals but did not make it into
RFC 6806.  We retain the definition so as to not break code implementing
the early draft, but need not document it.

Likewise, the krb5_octet_data structure and krb5_free_octet_data routine
are marked as having been originally introduced for PKINIT and "Do not
use this."  They are in fact unused, and should not be documented, but
the actual definitions must remain for compatibility.

ticket: 7489 (new)
tags: pullup
target_version: 1.11

Old versions of docutils will see inline markup (e.g., :ref:`foo`)
at the beginning of a line in the content of a directive block
and attempt to interpret that markup as options or arguments
to the directive.  RST intended as inline markup (as opposed to
modifying the behavior of the directive) will not be interpretable
in this context, and causes Sphinx to emit a warning.

Work around this behavior by always leaving a blank line before
the content of a directive block, forcing it to be interpreted
as content and not options or arguments.

The buggy behavior was only encountered in note environments, but
for consistency of style, also reformat warning and error blocks.

Note the new style constraint in doc/README.

ticket: 7469 (new)
title: doc buildslave generates sphinx warnings
tags: pullup
target_version: 1.11

Some convenience macros are referring to and dereferencing pointers,
and Sphinx will get a bit confused trying to interpret this as markup.
There should never be any markup intended to be interpreted in the
value of a macro definition, so we can silence this class of
warnings by treating them as literals.  (In some sense, they actually
are literals, too.)

This will cause a warning for macros that only cause a
symbol to be defined, that is, a literal "#define MACRO" with no
initializer, due to the lack of body in the inline-literal markup.
Such macros should probably be added to the exclude list for conversion
to reStructuredText in the Doxygen-Sphinx bridge, as was already
done for KRB5_OLD_CRYPTO.  Support code to programmatically omit
macros of this sort is deliberately *not* included, so that explicit
action must be taken when a new macro is to be undocumented.

Also, strip leading and trailing whitespace from the macro name,
since this causes problems with the markup.

ticket: 7447
tags: pullup
target_version: 1.11

Compress them onto one line for printing in the generated table.

ticket: 7447
tags: pullup
target_version: 1.11

Doxygen will pick up every function, macro, and typedef defined
in krb5.h; some of these may not actually be part of the public
API for one reason or another.  Provide hardcoded exclude lists
for macro/function/type names for which we do not want to emit
reStructuredText documentation, and check these lists when processing
the Doxygen XML output.

Seed these lists with the macros TRUE, FALSE, KRB5_OLD_CRYPTO,
KRB5_GENERAL__, KRB5_CALLCONV, KRB5_CALLCONV_C, KRB5_CALLCONV_WRONG,
KRB5INT_BEGIN_DECLS, KRB5INT_END_DECLS, and KRB5_ATTR_DEPRECATED,
and typedefs krb5_cc_ops and krb5_responder_context. The booleans
are compatibility cruft that we do not want to advertise, and the other
macros are for internal use for signalling and platform compatibility.
The typedefs are functioning just as forward declarations.

For consistency, remove KRB5_OLD_CRYPTO.rst from the macros index; it
had no content even when we did generate it.

ticket: 7447
tags: pullup
target_version: 1.11