#1628 cland_client erroneous errors on external files

[pecan]

@ Christo

TLDR:
  I forgot to create a compile_commands.json for the hidden dummy ~ProxyProject~
  and the goto function(s) info is missing for headers.
  Please check if my fix is messing up 'jdb' var.

Long winded explanation:

Clangd is reporting massive erroneous errors for files that do not belong
to the active project. It's caused because external files are represented
to clangd from a hidden dummy proxy project (~ProxyProject~) that does not
have a compile_commands.json (CCjson) file.
So clangd cobbles up compile info from only gods-know where.

Currently:
A single hidden 'Proxy_Project' is created whenever a workspace is created by
CodeBlocks.
clangd_client opens a ~ProxyProject~ (CC_ProxyProject.cbp) located in windows
Appdata\codebocks or Linux .config/codeblocks, copies the structure to the heap,
assigns it to the global 'GetParserManager()->GetProxyProject' pointer, then
closes the project so that it cannot interfere with CB or other plugins.
That leaves the proxyProject in what looks like an open state on the heap for
the life of the workspace.

I did this so that common code, which expects a project, would work for files
unassociated with a project just like it works for the active project. I also
expected to be able, in future, to handle single file compilations where no project
existed.  But... I forgot to create the CCjson for proxy project.

When coding clangd_client I forgot to create a proxyProject CCjson
file because, at the time, loading external files seem to work ok,
so I moved on to coding the presentation json output and forgot to go back
and create a CCjson for the files unassociated with a project and assigned to
proxyProject.

I know, I know! But I'm getting old...

During the coding of clangd_client, I only worked with a single project workspace.
So clangd had a CCjson it could infer compile info from.
Now, while coding debugger_dap, I have to work with a multi-project workspace.
Thus the errors raised their ugly head. clangd had no CCjson from which to infer compile
info.

Hopefully, this patch will fix that problem.

The fix:
The fix creates for the proxy project a compile_commands.json file.
It gets it's compile info from any project pointed to by the editor files
pProjectFile->parent. It does so with a dirty trick in UpdateCompilationDatabase(...)
by switching temporarily (if necessary) the project pointer from the proxy project to
the inactive project that actually owns the file (by way of the files'
.cbp pointer), thus getting the compile info from the ProjectBuildTarget pointer of the
inactive project in the workspace.
There will always be a Target build pointer since UpdateCompilationDatabase() requires
a project.

Files opened in an editor from in-active projects can thus be parsed correctly
by clangd.


The one gatcha:
I noticed when coding the fix that I was working near the code that you wrote
using a variable named 'jdb'. I seem to remember it had something to do with
make files. And I'm worried about weither my fix might f..k it up.

Would you please apply the fix to a safely temp version of clangd_client and look at
function "void ProcessLanguageClient::UpdateCompilationDatabase(cbProject* pProjectIn, wxString filename)
line:
    if ((jdb.size() == 0) && wxFileExists(compileCommandsFullPath)) switch(1)   //(christo 2024/06/26)
and see if there is any interference with variable 'jdb' from the fix code.

My guess is that the jdb code is caching entries from CCjson file of the active
project.

I can't see any interference with 'jdb', my fix only adds files,
which are not part of the active project, into the CCjson file of proxy project,
not the active project. My rix does not make any changes to the the CCjson of the
active project.

But, I can't be sure. So I plead your help.

Explanation ()purpose) of ~ProxyProject~
Closed hidden proxy project is used to represent files not parented by a project.
single non-project files (future)
non-active project files (this fix)
external file references for which compile info can be found.

Assorted Comments:

In ProcessLanguageClient::UpdateCompilationDatabase
line: wxString editorProjectDotCBP = pProject->GetFilename();
// If this is the proxy project, output to its compile_commands.json file.
// Eg., A file from a non-active project was opened into an editor.
// The file was assigned to the proxy project; so we need to create an entry
// into the proxy projects compile_commands.json file with the non-active projects'
// compile data because the dummy proxy project has no compile data.
// By switching back to the proxy project files' full path, this sameful trick
// will cause a compile_commands_json to be created for the proxy project,
//  but the compile data will be obtained from the files owning/parent project.
if (isProxyProject) editorProjectDotCBP = pProjectIn->GetFilename(); // (ph 26/08/18)


// This next statement will determines which projects' compile_commands.json file
// gets the clangd compile info.Either the active project or the proxy project.
wxString compileCommandsFullPath = wxPathOnly(editorProjectDotCBP) + "\\compile_commands.json";

@ Christo
After the above a jdb operaton occurs, we need to be determined if the
above code has caused problems with the 'jdb' operation.

Thanks // (ph 26/08/22)

[Christo]

Hi Pecan, jdb has nothing to do with external makefile projects, but it is to avoid parsing of compile commands json on every file parse at the startup. Please see [r13534] It is just a cache for optimisation which is dropped once all files are parsed. I don't think adding another file to it will create any issues.