Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

The nativeparser of codecompletion will block CB if travelling a large directory

(1/2) > >>

kipade:
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.

ollydbg:

--- Quote from: kipade on November 22, 2018, 04:57:49 am ---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.

--- End quote ---
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.

--- End quote ---
Which code snippet is wrong from you inspection? What do you mean by the "longest ancestor directory"?

kipade:
Im sorry for my poor english.
1) what I mean "marked", mightbe "referenced as A latter"
--- Quote from: ollydbg on November 23, 2018, 04:30:03 pm ---2) the code at the function "wxArrayString NativeParser::GetAllPathsByFilename(const wxString& filename)", from nativeparser.cpp
--- End quote ---

ollydbg:

--- 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);
    ...

--- End code ---

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?

ollydbg:

--- Quote from: ollydbg on November 27, 2018, 04:40:13 pm ---...
...
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?

--- End quote ---
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.

Navigation

[0] Message Index

[#] Next page

Go to full version