Author Topic: The nativeparser of codecompletion will block CB if travelling a large directory  (Read 8908 times)

Offline kipade

  • Multiple posting newcomer
  • *
  • Posts: 49
Im not sure somebody else would take this as a bug or not of codecompletion,
I remember I had reported it some years ago, but it still here.
condition:
1) create a project(I use c/c++) at one location, marked as A here.
2) import a file or directory recursive somewhere else.
3) select a .h file(without corresponding *.cpp) in the project manager, mark its parent dir as B.
here, A and B have the same ancestor directory C, and C is a large directory
with lots sub files and directories.

I took a look at the source code, the nativeparser will try to find its corresponding
source file in the longest ancestor directory between the file location and the project path,
and what a pity, this directory would be a very very large directory, then C:B was blocked
as expected.

I do not think that a good idea to do so. somebody, link me, would usually make projects
and source files in different directory, because there are some working project I want to
continuing working with C:B, and they are of course within my working directory. You also
can't prevent anybody from doing that.
« Last Edit: November 22, 2018, 04:59:21 am by kipade »

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5905
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Im not sure somebody else would take this as a bug or not of codecompletion,
I remember I had reported it some years ago, but it still here.
condition:
1) create a project(I use c/c++) at one location, marked as A here.
2) import a file or directory recursive somewhere else.
3) select a .h file(without corresponding *.cpp) in the project manager, mark its parent dir as B.
What do you mean by the word "mark"? I can't understand. Can you describe in more details?

Quote
here, A and B have the same ancestor directory C, and C is a large directory
with lots sub files and directories.

I took a look at the source code, the nativeparser will try to find its corresponding
source file in the longest ancestor directory between the file location and the project path,
and what a pity, this directory would be a very very large directory, then C:B was blocked
as expected.
Which code snippet is wrong from you inspection? What do you mean by the "longest ancestor directory"?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline kipade

  • Multiple posting newcomer
  • *
  • Posts: 49
Im sorry for my poor english.
1) what I mean "marked", mightbe "referenced as A latter"
2) the code at the function "wxArrayString NativeParser::GetAllPathsByFilename(const wxString& filename)", from nativeparser.cpp

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5905
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Code
wxArrayString NativeParser::GetAllPathsByFilename(const wxString& filename)
{
    TRACE(_T("NativeParser::GetAllPathsByFilename(): Enter"));

    wxArrayString dirs;
    const wxFileName fn(filename);

    wxDir dir(fn.GetPath());
    if (!dir.IsOpened())
        return wxArrayString();

    wxArrayString files;
    NativeParserHelper::ParserDirTraverser traverser(wxEmptyString, files);
    const wxString filespec = fn.HasExt() ? fn.GetName() + _T(".*") : fn.GetName();
    CCLogger::Get()->DebugLog(_T("NativeParser::GetAllPathsByFilename(): Traversing '") + fn.GetPath() + _T("' for: ") + filespec);

    dir.Traverse(traverser, filespec, wxDIR_FILES);
    ...

You mean the "traverser" will search files in folder of "dir" and all it's sub-folders?
And your "dir" has many files and sub-folders?

Which steps do I need to reproduce this bug?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5905
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
...
...
You mean the "traverser" will search files in folder of "dir" and all it's sub-folders?
And your "dir" has many files and sub-folders?

Which steps do I need to reproduce this bug?
By reading the function wxArrayString NativeParser::GetAllPathsByFilename(const wxString& filename), I see that I can answer the above questions myself.
This function just blindly traverser the project->GetCommonTopLevelPath() and all it's sub-folders.

I think this behavior is wrong, and a correct way to find a corresponding header/implementation file is just search the project files which belong to the cbp. An alternative way is to search the TokenFilenameMap of the TokenTree, so that the result matching files are the files which have been parsed by the Parser.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline kipade

  • Multiple posting newcomer
  • *
  • Posts: 49
Yes, you got it.  :)