Code completion toolbar disabled with source files

[travonz]

Hello,

I have problem since I upgrade to the last svn (6927). Previous upgrade was December the 8th, 2010 and everything was ok before and after this upgrade.
I use gentoo with gcc-4.4.4, wxgtk-2.8.10.
Code completion toolbar work well when a header file is open, but it is disabled in case of a source file.
Also, when I do a right-click on a function to find implementation, it never find anything, whereas finding declaration works well.
In my project, sources and headers are not in the same directory.

I tried code completion toolbar with codeblocks.cbp, everything works well. So the problem come from my project configuration.
But I can't find where it come from, do you think having sources and headers in different directories be the cause ? Or the extension of source files (.cc instead of .cpp) ?

Thank you very much for your help.

Xavier

[killerbot]

could you minimize your project (less files, less code in file) while still preserving the issue, that way you could attahc it here, and our CC gurus could try it out ?

[travonz]

Thank you very much for your answer.

Please find attached a minimalistic project which not compile but which reproduce the issue.

[killerbot]

I can confirm it does not work 100%.

In the header files, I could get the toolbar to contain stuff, but in the  .cc file not (for the few things I tried, maybe we should not generalize).
I could go from implementation through goto declaration to the declaration, but from the header  goto implementation sometimes failed.

@ our CC gurus, could you please have a look at this ...

[ollydbg]

I can confirm it does not work 100%.

In the header files, I could get the toolbar to contain stuff, but in the  .cc file not (for the few things I tried, maybe we should not generalize).
I could go from implementation through goto declaration to the declaration, but from the header  goto implementation sometimes failed.

@ our CC gurus, could you please have a look at this ...

I just test it now, it seems the *.cc file was not regard as a c++ language file, so the parser never parse on these files.

I will check the reason.

[ollydbg]

Ok, I find the bug by debugging a while.
the code snippet

Code

CCFileType CCFileTypeOf(const wxString& filename)
{
    const wxString file = filename.AfterLast(wxFILE_SEP_PATH).Lower();
    const int pos = file.Find(_T('.'), true);
    wxString ext;
    if (pos != wxNOT_FOUND)
        ext = file.SubString(pos + 1, file.Len());

    if (   ext.IsEmpty()
        || ext == _T("h")
        || ext == _T("hpp")
        || ext == _T("tcc")
        || ext == _T("xpm") )
    {
        return ccftHeader;
    }
    else if (   ext == _T("cpp")
             || ext == _T("cxx") )
    {
        return ccftCppSource;
    }
    else if (ext == _T("c"))
        return ccftCSource;
    else
        return ccftOther;
}

You see, the "cc" is not recognized as a cpp source, simply add this can solve the problem.

Hope some devs can fix this.

[MortenMacFly]

Ok, I find the bug by debugging a while.
the code snippet

Code

CCFileType CCFileTypeOf(const wxString& filename)
{
    const wxString file = filename.AfterLast(wxFILE_SEP_PATH).Lower();
    const int pos = file.Find(_T('.'), true);
    wxString ext;
    if (pos != wxNOT_FOUND)
        ext = file.SubString(pos + 1, file.Len());

    if (   ext.IsEmpty()
        || ext == _T("h")
        || ext == _T("hpp")
        || ext == _T("tcc")
        || ext == _T("xpm") )
    {
        return ccftHeader;
    }
    else if (   ext == _T("cpp")
             || ext == _T("cxx") )
    {
        return ccftCppSource;
    }
    else if (ext == _T("c"))
        return ccftCSource;
    else
        return ccftOther;
}

You see, the "cc" is not recognized as a cpp source, simply add this can solve the problem.

Hope some devs can fix this.

I think this needs refactoring anyways. we have the file association manager for this purpose which should be queried accordingly. Setting up an own file extension handler for CC doesn't make any sense IMHO.

[ollydbg]

I think this needs refactoring anyways. we have the file association manager for this purpose which should be queried accordingly. Setting up an own file extension handler for CC doesn't make any sense IMHO.

I do not agree, I have also noticed that, but that function was not satisfied with CC, because they treat like ".asm, .f.....“ files as source files.

see:

Code

FileType FileTypeOf(const wxString& filename)
{
    wxString ext = filename.AfterLast(_T('.')).Lower();

    if (ext.IsSameAs(FileFilters::ASM_EXT) ||
        ext.IsSameAs(FileFilters::C_EXT) ||
        ext.IsSameAs(FileFilters::CC_EXT) ||
        ext.IsSameAs(FileFilters::CPP_EXT) ||
        ext.IsSameAs(FileFilters::CXX_EXT) ||
        ext.IsSameAs(FileFilters::S_EXT) ||
        ext.IsSameAs(FileFilters::SS_EXT) ||
        ext.IsSameAs(FileFilters::S62_EXT) ||
        ext.IsSameAs(FileFilters::D_EXT) ||
        ext.IsSameAs(FileFilters::F_EXT) ||
        ext.IsSameAs(FileFilters::F77_EXT) ||
        ext.IsSameAs(FileFilters::F90_EXT) ||
        ext.IsSameAs(FileFilters::F95_EXT) ||
        ext.IsSameAs(FileFilters::JAVA_EXT)
       )
        return ftSource;

    else if (ext.IsSameAs(FileFilters::H_EXT) ||
             ext.IsSameAs(FileFilters::HH_EXT) ||
             ext.IsSameAs(FileFilters::HPP_EXT) ||
             ext.IsSameAs(FileFilters::HXX_EXT) ||
             ext.IsSameAs(FileFilters::INL_EXT)
            )
        return ftHeader;

    else if (ext.IsSameAs(FileFilters::CODEBLOCKS_EXT))
        return ftCodeBlocksProject;

    else if (ext.IsSameAs(FileFilters::WORKSPACE_EXT))
        return ftCodeBlocksWorkspace;

    else if (ext.IsSameAs(FileFilters::DEVCPP_EXT))
        return ftDevCppProject;

    else if (ext.IsSameAs(FileFilters::MSVC6_EXT))
        return ftMSVC6Project;

    else if (ext.IsSameAs(FileFilters::MSVC7_EXT))
        return ftMSVC7Project;

    else if (ext.IsSameAs(FileFilters::MSVC6_WORKSPACE_EXT))
        return ftMSVC6Workspace;

    else if (ext.IsSameAs(FileFilters::MSVC7_WORKSPACE_EXT))
        return ftMSVC7Workspace;

    else if (ext.IsSameAs(FileFilters::XCODE1_EXT))
        return ftXcode1Project; // Xcode 1.0+ (Mac OS X 10.3)

    else if (ext.IsSameAs(FileFilters::XCODE2_EXT))
        return ftXcode2Project; // Xcode 2.1+ (Mac OS X 10.4)

    else if (ext.IsSameAs(FileFilters::OBJECT_EXT))
        return ftObject;

    else if (ext.IsSameAs(FileFilters::XRCRESOURCE_EXT))
        return ftXRCResource;

    else if (ext.IsSameAs(FileFilters::RESOURCE_EXT))
        return ftResource;

    else if (ext.IsSameAs(FileFilters::RESOURCEBIN_EXT))
        return ftResourceBin;

    else if (ext.IsSameAs(FileFilters::STATICLIB_EXT))
        return ftStaticLib;

    else if (ext.IsSameAs(FileFilters::DYNAMICLIB_EXT))
        return ftDynamicLib;

    else if (ext.IsSameAs(FileFilters::NATIVE_EXT))
        return ftNative;

    else if (ext.IsSameAs(FileFilters::EXECUTABLE_EXT))
        return ftExecutable;

    else if (ext.IsSameAs(FileFilters::XML_EXT))
        return ftXMLDocument;

    else if (ext.IsSameAs(FileFilters::SCRIPT_EXT))
        return ftScript;

    // DrewBoo: Before giving up, see if the ProjectManager
    // considers this extension a source or header
    // TODO (Morten#5#): Do what DrewBoo said: Try removing the above code
    // TODO (Morten#3#): This code should actually be a method of filegrous and masks or alike. So we collect all extension specific things in one place. As of now this would break ABI compatibilty with 08.02 so this should happen later.
    else
    {
        ProjectManager *prjMgr = Manager::Get()->GetProjectManager();
        if ( prjMgr )
        {
            const FilesGroupsAndMasks* fgm = prjMgr->GetFilesGroupsAndMasks();
            if (fgm)
            {
               for (unsigned int i = 0; i != fgm->GetGroupsCount(); ++i)
               {
                    if (fgm->GetGroupName(i) == _T("Sources") && fgm->MatchesMask(ext, i))
                        return ftSource;
                    if (fgm->GetGroupName(i) == _T("Headers") && fgm->MatchesMask(ext, i))
                        return ftHeader;
               }
            }
        }
    }

    return ftOther;
}

[MortenMacFly]

I do not agree, I have also noticed that, but that function was not satisfied with CC, because they treat like ".asm, .f.....“ files as source files.

That's why I said "re-factoring". I know it's not perfect now, but we really should have everything in once place. The supported file extensions should arise from the file extensions as setup by the user in "categories and file types", probably in combination with the editor settings (as fall-back). For me it just makes no sense at all to handle file extensions in many places.

[killerbot]

Seems to me the mentioned refactoring would improve the code, but can we agree that for quick fix, we add .cc extension in the suggested place in the CC plugin itself ?

[MortenMacFly]

but can we agree that for quick fix, we add .cc extension in the suggested place in the CC plugin itself ?

Sure, go ahead. I've no SVN access atm. Don't forget possible endings are: *.cc; *.cpp; *.cxx; *.c++. I've seen all of them, including upper case variants... ;-)

[killerbot]

done : added "cc" and "c++"

Casing should be handled in the comparison (case insensitive). rev 6930

@OP : could you build the latest svn and retry it on your code in your environment ? For me the example project you provided works ok now.

[travonz]

Everything works well on the complete project.
Thanks for the quickness and efficiency of your work.

Xavier