fix: crash on unimplemented when populating overloads destructor entry #922
Conversation
|
An automated preview of the documentation is available at https://922.mrdocs.prtest2.cppalliance.org/index.html |
alandefreitas
force-pushed
the
fix-destructor-overloads-from-class
branch
from
1a631d4 to
91e0e11
Compare
|
An automated preview of the documentation is available at https://922.mrdocs.prtest2.cppalliance.org/index.html |
| @@ -76,6 +76,10 @@ populateOverloadsFromClass(OverloadsInfo& I) | |||
| return true; | |||
| } | |||
| case FunctionClass::Destructor: | |||
| { | |||
There was a problem hiding this comment.
Destructor overloads?
There was a problem hiding this comment.
Isn't the problem in the calling function?
There was a problem hiding this comment.
If you accept the logical consistency about having a destructor overload set which can only be a single element.
The resulting adoc looks perfectly reasonable. Maybe we could just rename the brief to 'Destructor' instead of 'Destructors'?
There was a problem hiding this comment.
Yes. You could be correct in theoretical terms. What I mean is that, in practical terms, as an implementation detail of MrDocs, where an overload set must have at least two members, that code is unreachable. If it's being reached, there's a bug somewhere else we need to fix. Or maybe it should be reachable for some reason I haven't understood yet.
Even if the resulting adoc looks good in terms of what we were able to investigate so far, we still have a problem here, and we have to understand why it's happening and what else it's affecting in the corpus and the output.
I am not sure why this is not seen in CI presently, but I can reproduce it when building mrdocs from the llvm version bundled in homebrew (currently 20.1.7).
alandefreitas
force-pushed
the
fix-destructor-overloads-from-class
branch
from
91e0e11 to
b864c03
Compare
|
An automated preview of the documentation is available at https://922.mrdocs.prtest2.cppalliance.org/index.html |
I am not sure why this is not seen in CI presently, but I can reproduce it when building mrdocs from the llvm version bundled in homebrew (currently 20.1.7).