jomiller / vscode-rtags

RTags Client for Visual Studio Code
GNU General Public License v3.0
10 stars 0 forks source link

[RTags] Could not load the compilation database for workspace folder issue #29

Open 3gx opened 4 years ago

3gx commented 4 years ago

I am keep getting

[RTags] Could not load the compilation database for workspace folder: /path/to/my/project. 
The compilation database /path/to/my/project/compile_commands.json is already loaded at another project root: /path/to/my/project

If add compile_commands.json for the first time, all works, but then if I reload rtags extensions, if I change setting, or close & reopen VSCode, I am starting to get the same error.

I do remote development on Linux from Mac host. I have no clue how to undo this issue, I clean all .vscode* files, on remote and local machine, kill remote vscode server processes, clean-up local and remote configuration to run VS code from scratch, but this errors stays. I can add a new project, can use rtags, until rtags reloads, and I get this kind of error for this new project.

Any clue what is going on, and how to resolve this? Thanks

3gx commented 4 years ago

I use VSCode 1.39.2 on Mac OS X Mojave host. Remote is Ubuntu 18.04 LTS.

3gx commented 4 years ago

I was able to workaround the issue by commenting out the following lines:

(commit 4c87804) https://github.com/jomiller/vscode-rtags/blob/master/src/rtagsManager.ts#L949 https://github.com/jomiller/vscode-rtags/blob/master/src/rtagsManager.ts#L1067

and changing line https://github.com/jomiller/vscode-rtags/blob/master/src/rtagsManager.ts#L1067

to

const selectedAction = keepAction;

the modification were done directly on out/rtagsManager.js equivalent code, since I don't know how to build extension from sources.

Josie-H commented 3 years ago

I hit this, and solved it instead by running "rtags-rdm --clean-slate" outside of VSCode, before reloading VSCode. I assume therefore that it's got something to do with the fact that rtags server by default keeps tag data between runs, and the extension can't handle that old data. Desired behaviour is probably that we don't reindex everything - at least on my codebase where it takes half an hour!