clang_complete stops working in editing session

[TheBitshifter]

I'm using clang_complete currently commit b1a507fbc27ef581c966b035f52eafae773a6f32

Sometimes during my editing session, clang_complete seems to cease using libclang for the completions.

When I write something like foo-> I get a completion window that includes things like namespaces and all the identifiers in my current file instead of the context aware completion.

I can grab the string from "Command: clang " in the messages from the command line and the completion is correct. If I re-start vim, and try again everything works. I haven't seen any other way of re-setting clang_complete. Unfortunately, it doesn't seem to be repeatable. Any help would or pointers to where I can start debugging would be nice.

One small thing I've noticed the line that says "Get TU: X.XXXs (y%)" seems to go to 0.

[xaizek]

I doubt it's related to the plugin. I think that list that includes "everything" also appears when completion fails due to unrecoverable parsing errors. In this case something probably goes wrong inside libclang too.

[TheBitshifter]

I don't know what is going on in the plugin, I don't see anything related to parse errors in the messages. Also if I run the command that it shows outside vim, it parses fine and presents completions. If I restart vim, nothing else, no alterations to any of the source files, it starts working again.

Some piece of state held either in the reference to libclang or clang_complete seems like the only explanation for this behavior.

[xaizek]

Some piece of state held either in the reference to libclang or clang_complete seems like the only explanation for this behavior.

libclang caches translation unit in some way and reparses it only partially, this can be the reason why it fails, if cache gets broken in some way (could be because of the way library is used of course, but then it should happen more often, unless it's a subtle bug).

Related parts are here and here. Maybe try commenting it out, but completion will probably become more slow then.

[TheBitshifter]

So, I had a chance to look in to this today and I just hit my issue. I added the following lines to libclang.py:

183   if int(vim.eval("!exists(\"g:clang_goofed_up\")")) == 1:
184     vim.command("let g:clang_goofed_up = 0")
185   if (int(vim.eval("g:clang_goofed_up")) == 1):
186     translationUnits[fileName] = None
187     vim.command("let g:clang_goofed_up=0")
188     print("Hit the clang_goofed_up clause");

After I hit the issue, I set g:clang_googed_up to 1 and tried again so this code got hit and re-inited the translation unit and it started working correctly again. I still have no idea what is wrong with the translation unit object, but it is at least a workaround for me that doesn't involve re-starting vim. Is something like this an acceptable solution for upstream? If not, what would you like to see?

[xaizek]

If it's a bug in libclang, I think it just needs to be fixed there.