don't mark unnamed classes as implementation defined

[mizvekov]

These classes can appear as user written code and needs to be documented, as show in the new test case.

In general, for implementation defined declarations, we can detect them as the clang AST exposes them as 'implicit', but this is possible for any declaration, and can be handled more generally.

This is related to #1054: We have no way to mark these classes as implementation defined with this change.

This is also related to #1055, as the HTML generator has some issues printing unnamed entities.

Fixes #1035

[cppalliance-bot]

An automated preview of the documentation is available at https://1051.mrdocs.prtest2.cppalliance.org/index.html

If more commits are pushed to the pull request, the docs will rebuild at the same URL.

2025-10-07 18:07:06 UTC

[alandefreitas]

From what we discussed so far, I think this is good to go as soon as we move the fixtures from the snippets directory.

Please open new issues to decide what to do about and to fix the other cases:

1. when the user documents the variable rather than the record,
2. when the record is shown in the member's table of the parent namespace (it seems like it's simply not there right now), and
3. when the user wants to make the record implementation defined (for now, users have to give it a name to mark them as implementation defined / maybe besides the documentation tag, the thing we just removed could be an option to make unnamed records regular or implementation defined by default).

(edit: reformatted the list for clarity)

[mizvekov]

@alandefreitas I am not sure what you mean by:

2) when the record is show in the member's table of the parent namespace (it seems like it's simply not there right now)

I don't see a problem here, can you clarify?

[alandefreitas]

In other words, what I tried to do is:

1. More or less the problem you complained about
2. More or less the problem Vinnie is complaining about
3. More or less the problem the Boost.OpenMethod guys were complaining about

So (1) extracting comments for the variables is just a feature MrDocs is not supporting yet. It's a matter of correctness so I think (1) is not controversial at all.

But (2) extracting the element as regular and (3) extracting it as implementation defined as in direct conflict, but we still need to solve both by handling their root causes.

In fact, the logic this PR is removing was inserted because of the complaint we received in (3). Namely, they wanted the unnamed struct to be implementation defined. But they couldn't make it implementation defined because it's unnamed so they're nothing they can use in the configuration file in the implementation-define option. The solution was to just make all such unnamed structs implementation defined. Now we need to do better because this is in conflict with (2). The only way I can see (3) work is by defining a comment the user can use in the documentation to directly mark that symbol as implementation defined.

In (2), however, Vinnie wants not only to render these symbols. He wants them to be rendered and he wants them to be displayed in members tables somehow. We would give them names and everything. This is obviously in direct conflict with (3). His use case is completely different. MrDocs doesn't support niebloids yet (see #564) so he just wants to have the functor and the variable displayed in the documentation without having to give the functor a name.

That's why these would be three issues. Please let me know if this clarifies things a little.