Extraction

By default, members appear alphabetically within each kind. The sort-members family overrides that order when you want a more conventional grouping (constructors first, destructors first, conversions and relational operators last, and so on).

The other sort switches (sort-members-ctors-1st, sort-members-dtors-1st, sort-members-assignment-1st, sort-members-conversion-last, sort-members-relational-last) refine which member kinds float to the top or sink to the bottom. sort-members-by and sort-namespace-members-by pick between alphabetical and declaration order.

A C++ overload set is many functions sharing a name. overloads merges them into a single page so the reader sees the whole set at once instead of one page per signature:

sfinae rewrites SFINAE constraints into a readable form instead of the raw enable_if machinery:

auto-function-objects detects the Algorithm Function Object (AFO) idiom and presents the variable’s page as if it were a function, using the call operator’s doc comment, parameters, and return type:

MrDocs fills several kinds of metadata from the signature when the doc comment leaves them out. Each kind is governed by its own switch.

When a class inherits from another, inherit-base-members determines how the inherited members should appear in the documentation.

never: The strictest setting lists the base relationship but does not repeat the base’s members on the derived page. This is the style used by cppreference. Readers follow the link to the base to see what they inherited:

circle's page lists only its own constructor. The inherited draw is reachable through the link to shape. This is the model cppreference uses for the standard library. Technically correct, but most library docs do not want it: a reader landing on circle has to chase a link to find out what they can call on it.

reference: lists the inherited members directly on the derived class’s page. Each entry links back to the member of the base class, so the base class is the source of truth:

draw is now visible in circle's Member Functions table, alongside the constructor. Its link points at shape::draw, so there is no duplicate page. This is the natural choice when every base class lives in the corpus and has its own page.

copy-dependencies (the default) is meant to handle specializations more gracefully. The motivation for this option is that two patterns break the reference model:

In both cases, the reference option would leave the inherited members invisible or create a reference to a primary template that’s semantically hard to interpret. The default, copy-dependencies, behaves like reference when the base is already in the corpus. However, it uses the C++ compiler to actually instantiate the members for other cases, and copies the members of the instantiated base class into the derived page when the base is a dependency, so they are documented in place with the concrete operand types substituted in:

The configuration marks the detail namespace as implementation-defined, so neither the primary template detail::comparable nor any of its symbols have a page of their own and every reference to one of them renders as /* implementation-defined */. version's base class in the rendered synopsis is exactly that placeholder. The specialization detail::comparable<version> is therefore a pure dependency. copy-dependencies reaches into that instantiated base and copies its members onto version's page: operator== and operator!= appear in version's Member Functions table, with the parameter type rewritten to version const& and the boilerplate brief, parameter doc, and return value supplied by auto-function-metadata. The reader gets the full API of version in one place, with nothing referring outwardly to a base that has no page.

This is one of the larger gaps between MrDocs and other tools. Other tools could at most document the primary comparable<T> and report the inheritance, but the implicit specialization comparable<version> is not an entity that can be introspected without a compiler. The inherited operators silently disappear from version's page, and the Boost.Operators / CRTP idiom becomes invisible in the rendered docs. MrDocs treats the specialization as a first-class dependency and copies the resolved members into the derived class.

copy-all: The last possible setting copies every base member into every derived page, regardless of whether the base is in the corpus. It flattens the documentation: a reader on a derived page sees the full surface inline, with no need to follow base-class links. The price is duplication: the same member is documented on every class that inherits it.

The platform for a documentation build often doesn’t have the same dependencies and system libraries available. If a header is genuinely unavailable, the Migration Notes walk through the practical solutions. One of them is defining shims for these dependencies. The other options can be specified in the configuration file.

missing-include-shims lets you describe stub contents for individual headers directly in the configuration file (the key is the include path, the value is the file body MrDocs presents to the compiler):

missing-include-prefixes tells MrDocs which include paths to forgive when they cannot be found, so the surrounding code parses anyway:

Reach for these only when you need to. They are the answer to "MrDocs can’t find this header and I cannot install it"; if you can adjust the compilation database, that is the better path.