CC doxygen processing: potential bug?

[Alpha]

In reading through, I noticed the following:

Code: plugins/codecompletion/doxygen_parser.cpp:547

wxString DocumentationHelper::DoxygenToHTML(const wxString& doc)
{
    using namespace HTMLTags;

    wxString arguments[5];
    wxString &plainText = arguments[0], brief = arguments[1], params = arguments[2],
        seeAlso = arguments[3], returns = arguments[4];

[...]

    // process nested keywords:
    for (size_t i = 0; i < (size_t)(sizeof(arguments)/sizeof(arguments[0])); ++i)
    {
        arguments[i].Trim(true).Trim(false);

        Doxygen::DoxygenParser dox_parser;
        int dox_keyword = dox_parser.FindNextKeyword(arguments[i]);
        while (dox_keyword < Doxygen::KEYWORDS_COUNT)
        {
            using namespace Doxygen;
            switch (dox_keyword)
            {
            case B:
                {
                    dox_parser.ReplaceCurrentKeyword(arguments[i], b1);
                    wxString arg0;
                    dox_parser.GetArgument(arguments[i], RANGE_WORD, arg0);
                    arguments[i].insert(dox_parser.GetPosition() + 1, b0);
                }
                break;
            default:
                break;
            }
            dox_keyword = dox_parser.FindNextKeyword(arguments[i]);
        }
    }// for (i)

[...]

Only plainText is declared as a reference, so the following loop (the only place where arguments[] is used) does not appear to do any useful work.

However, I am not sure of the intent of this code, so I do not know what type of bug to even try to look for.  Thoughts?

[ToApolytoXaos]

In reading through, I noticed the following:

Code: plugins/codecompletion/doxygen_parser.cpp:547

wxString DocumentationHelper::DoxygenToHTML(const wxString& doc)
{
    using namespace HTMLTags;

    wxString arguments[5];
    wxString &plainText = arguments[0], brief = arguments[1], params = arguments[2],
        seeAlso = arguments[3], returns = arguments[4];

[...]

    // process nested keywords:
    for (size_t i = 0; i < (size_t)(sizeof(arguments)/sizeof(arguments[0])); ++i)
    {
        arguments[i].Trim(true).Trim(false);

        Doxygen::DoxygenParser dox_parser;
        int dox_keyword = dox_parser.FindNextKeyword(arguments[i]);
        while (dox_keyword < Doxygen::KEYWORDS_COUNT)
        {
            using namespace Doxygen;
            switch (dox_keyword)
            {
            case B:
                {
                    dox_parser.ReplaceCurrentKeyword(arguments[i], b1);
                    wxString arg0;
                    dox_parser.GetArgument(arguments[i], RANGE_WORD, arg0);
                    arguments[i].insert(dox_parser.GetPosition() + 1, b0);
                }
                break;
            default:
                break;
            }
            dox_keyword = dox_parser.FindNextKeyword(arguments[i]);
        }
    }// for (i)

[...]

Only plainText is declared as a reference, so the following loop (the only place where arguments[] is used) does not appear to do any useful work.

However, I am not sure of the intent of this code, so I do not know what type of bug to even try to look for.  Thoughts?

I don't know why Alpha, but I have a feeling that the code's creator original intention was to create something like a series of variables of type wxString &. It resembles so much to the <type specifier> * issue most C developers have with pointers. Maybe the poor guy was too tired when he was creating this piece of code and missed the original concept (intention)? Possible and plausible for sure; it happens often to each and every one of us

[p2rkw]

Hi, it seems that I'm author of this code (doxygen 'parser' and popup) My first idea was to increase readability: use array inside loop and reference afterwards. Lets say 'named array elements'. In fact ampersands are missing.

[Alpha]

So because the loop has technically not been used, and no problems were noticed from that, can the array and the loop be completely removed?  Or is there a case in which this produces incorrect results?

[p2rkw]

Now I see I should write more comments.
First loop (while) looks for keywords that affect whole paragraph, and (should) store these paragraphs inside array "arguments", then second loop (for) looks for nested keywords inside spitted paragraphs. So this is definitely a bug. Paragraphs should be accessible in both ways.
Try to run parser on this, to see a bug:

Code

/*! Detailed description starts here.
  \b Bold is now @b supported
  @sa this will not be @b bold
*/
int a;

[Alpha]

Committed.