ASSERT(0) in docnode.cpp

[kjellahl]

Starting with doxygen 1.9.3 the ASSERT(0) statement in docnode.cpp, DocPara::handleCommand()
can be reached. The attached doxytest.h file is an example of a file that triggers
this message. It's part of a longer file that produces several ASSERT messages.

I made some tests with gdb and saw that cmdId = 103 (CMD_SETSCOPE) which
is not a case in the big switch statement.
Tested with doxygen 1.12.0 (7b32bc3).

doxytest.zip

[albert-github]

The probem in this case looks like to be the markdown conversion from > to <blockquote>, more precise the detection of the end of the range, seen:

======== Markdown =========
---- input -------
The action that this activatable will activate and receive
 updates from for various states and possibly appearance.

 > Gtk::Activatable implementors need to handle the this property and
 > call Gtk::Activatable::do_set_related_action() when it changes.

 @deprecated Use Gtk::Actionable::property_action_name() on Gtk::Actionable widgets instead.

---- output -----
The action that this activatable will activate and receive
 updates from for various states and possibly appearance.

<blockquote>&zwj;Gtk::Activatable implementors need to handle the this property and
call Gtk::Activatable::do_set_related_action() when it changes.

 @deprecated Use Gtk::Actionable::property_action_name() on Gtk::Actionable widgets instead.
</blockquote>
=========

[doxygen]

@kjellahl Please verify if the referenced commit fixes the problem for you. Do not close the issue, this will be done automatically when the next official release becomes available.

[kjellahl]

Yes, the 7673d22 commit fixes the problem.

[albert-github]

The problem as indicated in the issue is solved but there is another issue hidden in the issue that is still present and that was revealed in the issue as well when the markdown translation was done.
When having:

/// \file
// Generated by gmmproc 2.66.7 -- DO NOT MODIFY!
#ifndef _GTKMM_ACTIVATABLE_H
#define _GTKMM_ACTIVATABLE_H

class GTKMM_API Activatable : public Glib::Interface
{
public:

/** The action that this activatable will activate and receive
   * updates from for various states and possibly appearance.
   *
   * <blockquote>
   * Gtk::Activatable implementors need to handle the this property and
   * call Gtk::Activatable::do_set_related_action() when it changes.
   *
   * @deprecated Use Gtk::Actionable::property_action_name() on Gtk::Actionable widgets instead.
   * </blockquote>
   */
  Glib::PropertyProxy< Glib::RefPtr<Action> > property_related_action() ;

/** The action that this activatable will activate and receive
   * updates from for various states and possibly appearance.
   *
   *  Gtk::Activatable implementors need to handle the this property and
   *  call Gtk::Activatable::do_set_related_action() when it changes.
   *
   * @deprecated Use Gtk::Actionable::property_action_name() on Gtk::Actionable widgets instead.
   */
  Glib::PropertyProxy_ReadOnly< Glib::RefPtr<Action> > property_related_action() const;

};
} // namespace Gtk

#endif /* _GTKMM_ACTIVATABLE_H */

we still see the issue.
Note that the issue is not present when we don´t see the issue!

Example: example.tar.gz

[doxygen]

@albert-github Pushed a fix for the underlying issue. Doxygen will now report warning: found </blockquote> tag without matching <blockquote> inside deprecated, because the end of the block quote is taken as part of the @deprecated command (this command ends at a new paragraph).

[albert-github]

@doxygen

• I saw that part of the commit was reverted, so is it still ongoing work? I still get the warnings:

  deprecated:4: warning: Unexpected tag <dt> found
  deprecated:5: warning: Unexpected tag <dd> found
  

  Note I don't think the initial warning found </blockquote> tag without matching <blockquote> wouldn't be nice either.
• the problem was specified for the <blockquote> tag but it is not limited to this, e.g. <details> also has this problem, though it looks like this gives after the "partly reverted commit" the same messages as <blockquote>.

[doxygen]

@albert-github The fix revealed an existing problem in the markdown processing (extra end of blockquote) which now triggered a warning and caused the manual generation step of the build to fail. I fixed this now. Also included the details command.

[albert-github]

• I still get the warnings like:

  deprecated:3: warning: found </blockquote> tag without matching <blockquote>
  deprecated:3: warning: found </blockquote> tag without matching <blockquote>
  

• in CGAL there was the warning before (135d4c6) as well but this is now gone (they used now 0621149)

[albert-github]

Looks like that there are more HTML / XML tags that cause problems in relation to \deprecated etc.
E.g. <code> where the code is ended by the \xrefitem command analogous for the <pre> (and probably more, didn't investigate yet. Probably <blockquote> / <details> / <code> / <pre> should be solved first before further testing).