Author Topic: Goto function bug  (Read 6006 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5491
Goto function bug
« on: December 12, 2005, 09:24:09 pm »
Hi,

Did not file bugreport on source forge yet, first I'dd like a confirmation please.
Consider the following code (create a console app with it) :
Code
#include <iostream>
#include <vector>
#include <deque>
#include <iterator>
#include <algorithm>

using namespace std;

bool IsEven(int elem)
{
return elem%2 == 0;
} // end of IsEven

bool AbsLess(int elem1, int elem2)
{
return abs(elem1) < abs(elem2);
} // end of AbsLess

int main()
{
int Dummy[] = {11, 2, 3, 4, 5, 4, 3, 18, 1, 9, 10};
vector<int> v(Dummy, Dummy + sizeof(Dummy)/sizeof(*Dummy));
deque<int> d(v.begin(), v.end());

// count all 4's in the vector
int n4v = count(v.begin(), v.end(), 4);
cout << "We found " << n4v << " instances of 4" << endl;

int nEven = count_if(d.begin(), d.end(), IsEven);
cout << nEven << " elements are even." << endl;

int MinElement = *min_element(v.begin(), v.end());
int MaxElement = *max_element(d.begin(), d.end());
cout << "The minimum of the set is " << MinElement << " , and the maximum is " <<
MaxElement << endl;

// with our own compare function
// op(elem1, elem2) : return true if elem1 is less then elem2
int Dummy2[] = {2, 3, 4, 5, 6, 7, 8, -3, -2, -1, 0, 1, 2, 3, 4, 5};
deque<int> coll(Dummy2, Dummy2 + sizeof(Dummy2)/sizeof(*Dummy2));
cout << "minimum of the absolute values: " <<
*min_element(coll.begin(), coll.end(), AbsLess) << endl;
cout << "maximum of the absolute values: " <<
*max_element(coll.begin(), coll.end(), AbsLess) << endl;

return 0;
} // end of main

Now do the following : Search menu -> goto function.
3 functions turn up, but look at their return values !!! Each function prepends the return values of the functions in front of it.
bool
boolbool
boolboolint
Seems like a bug to me ;-)

kind regards,
Lieven

[attachment deleted by admin]

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Goto function bug
« Reply #1 on: December 12, 2005, 09:31:24 pm »
I can confirm this with both C::B RC2 and SVN C::B rev1447 (Windows XP SP2).

Michael

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5491
Re: Goto function bug
« Reply #2 on: December 12, 2005, 09:49:33 pm »
Some first debug findings :

The action takes place in :
void CodeCompletion::OnGotoFunction(wxCommandEvent& event)

A parser is created and set to work, next the tokens are retrieved, in these tokens the bug is already present.
tokens:
  tokens[0] : m_Type : bool, m_ActualType : bool, m_Name : IsEven, m_DisplayName : IsEven(int elem):bool

  tokens[1] : m_Type : boolbool, m_ActualType : boolbool, m_Name : AbsLess, m_DisplayName : AbsLess(int elem1, int elem2):boolbool

That means the damage is done inside :
   Parser parser(this);
   parser.ParseBufferForFunctions(ed->GetControl()->GetText());

Lieven

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5491
Re: Goto function bug
« Reply #3 on: December 12, 2005, 10:23:27 pm »
some more debug info :
Token* ParserThread::DoAddToken(TokenKind kind, const wxString& name, const wxString& args, bool isOperator)

The first time we end up here (first function) m_Str is "bool"
The second time it is boolbool.
So it seems this variable does not get reset.
Question : Should we reset at the end of DoAddToken ??
Or should we reset at the end of HandleFunction ??
Or should we reset it in ParseBufferForFunctions just after the call to HandleFunction() ??

I have tried the latter solution (reset it in ParseBufferForFunctions just after the call to HandleFunction() ), and this fixed the problem (see screenshot).

Yiannis, it is up to you to make the final judgement if this is really the correct place for the reset of m_Str. Maybe the problem shows up in other parsing control flows ??



[attachment deleted by admin]

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Goto function bug
« Reply #4 on: December 12, 2005, 11:19:58 pm »
Yiannis, it is up to you to make the final judgement if this is really the correct place for the reset of m_Str. Maybe the problem shows up in other parsing control flows ??

Yup, that's the place :)
Be patient!
This bug will be fixed soon...