Clang CC

[yvesdm3000]

OK I'll hande/implement this first in the plugin, but I'll make sure I can easily move it to C::B later on. This enables me to keep using stock code::blocks and the early adopters have less work following progress since they don't have to patch codeblocks.

Looks like XCode replaces the whole line with the fixit when not yet applied and reverts that if you don't apply it. The choice to apply it is not really a button but a context-menu similar to the CodeCompletion-context-menu.

About the confusion with the error/warning annotations, I would not change the existing behaviour, I treat these fixits as something extra, so there can be an error-annotation saying there is a missing ')' and also a fixit that pre-visualizes the ')' at the end. For now I only need something extra for the 'apply'-button/menu/whatever.

Yves

[yvesdm3000]

As for me a couple of shortcuts would suffice

I'm aware we lack operations on these warning/errors. I would at least need goto next/previous error/warning with good shortcuts. It's however pretty confusing since there are also the build error/warnings which are not necessarily from the same compiler.
I also think it would be a good idea to have a separate output view that outputs there errors, similar to the build messages. Maybe some people don't like them to be inlined, it would also give a more global overview of the amount of warning/errors.

Yves

[oBFusCATed]

I also think it would be a good idea to have a separate output view that outputs there errors, similar to the build messages.

Please don't do this, we have too many logs already, and I'm sure more people won't like the new log pane, then the integrated annotations!

Maybe some people don't like them to be inlined, it would also give a more global overview of the amount of warning/errors.

You'll have to find a way to reuse one of the compiler logs or even both. Probably we should move them to the sdk somehow.

[yvesdm3000]

I compiled a version for Windows now. It seems to work fine but makes CodeBlocks very unstable, disappearing widgets etc... Still need to figure out why that happens before I publish a binary.

Yves

[yvesdm3000]

I released an alpha-version for Windows here:

https://github.com/yvesdm3000/ClangLib/releases/tag/0.3.1

All constructive feedback is welcome.

Yves

[MortenMacFly]

All constructive feedback is welcome.

I've added a tiny note on commit:

https://github.com/yvesdm3000/ClangLib/commit/d0d558a1bf5ffe00b3a6dfc4ee816ea6fb48be2a

[yvesdm3000]

All constructive feedback is welcome.

I've added a tiny note on commit:

https://github.com/yvesdm3000/ClangLib/commit/d0d558a1bf5ffe00b3a6dfc4ee816ea6fb48be2a

I now incorporated your suggestion.

Too bad the tabjump doesn't work on Windows, the way I implemented it is probably a little bit too hackish.

Maybe I should add this to the Scintilla wrapper class instead, so that the other CC implementations can use it too ? It would solve the "hack"-issue too...

The feature allows you to jump to the next parameter of a function that was inserted with CC, using the Tab-key. This also selects the placeholder text so that the user can easily start typing the parameter value.
This works nicely on Linux.

Yves

[l_inc]

yvesdm3000
You made a whole bunch of methods public, which rendered the plugin unusable, cause the vector of TUs now works with them as with copyable objects, which results in exceptions (("Illegal copy attempted of TranslationUnit object.")). Btw. the "-ansi" option must be removed, cause it disables many features of C++11.

Another problem is that the plugin works for a single TU only if there are multiple open.

[yvesdm3000]

yvesdm3000
You made a whole bunch of methods public, which rendered the plugin unusable, cause the vector of TUs now works with them as with copyable objects, which results in exceptions (("Illegal copy attempted of TranslationUnit object.")). Btw. the "-ansi" option must be removed, cause it disables many features of C++11.

Another problem is that the plugin works for a single TU only if there are multiple open.

Can you be a little bit more specific? Do you use the precompiled version or do you compile it yourself? The error you are complaining about is only enabled when C++11 is enabled so I assume you compile the plugin yourself.
C++11 is not a requrement since that is not what C::B uses...  I even don't test it for C++11 since I want to focus on implementing features first and make the changes for C++11 later (it's easier to move from old to new C++). I know there is the move-operator and stuff that is defined away, but currently that is not supposed to be enabled for now. I can even imagine it doesn't work at all because I swap away a TU that is being reparsed, to move it out from under the lock, you get huge congestion otherwise, blocking everything while parsing/reparsing.

For me the plugin does not work with a single TU, it switches TU when the associated document is opened. And I happen to push a change a couple of hours ago that fixes the "Find imlementation" to search across multiple TU's. Obviously those TU's need to be opened first... Code-completion only needs 1 TU. If you want symbols from non-included headers, better include the header then.

Regarding broadening the scope for the "Find implementation" to the full project, that is still a TODO and I think it's better to implement persistency of the internal database first and then do any indexing of all the documents in the project.

I remind you this is only a prerelease and by all means not a final product, although I do use it for my daily main job now.

Yves

[l_inc]

yvesdm3000

Can you be a little bit more specific?

Sorry, I was in a hurry. I do indeed compile the plugin. Precompiled versions of CodeBlocks plugins seem to me only good when being part of a distribution. Otherwise their usefulness scope is too limited.

I even don't test it for C++11 since I want to focus on implementing features first and make the changes for C++11 later

Wouldn't you be willing to consider dropping support for C++ older than C++11 at all? C++11 is safer in many ways. E.g. much safer would be to have a vector of unique_ptr's to TUs with enforced move-semantics than having these dirty swap-hacks in a copy-constructor. I see no reason to continue suffering in supporting the older standards. I would even expect the "mysterious crashes" you are talking about in your todo-list to go away after conscientiously switching to C++11.

I remind you this is only a prerelease and by all means not a final product, although I do use it for my daily main job now.

I understand that. I was just shocked to see the commented private replaced with public and the private methods being used outside of the class scope. This made me scared about the project becoming a heap of crutches even before the first release would come out.

[yvesdm3000]

I remind you this is only a prerelease and by all means not a final product, although I do use it for my daily main job now.

I understand that. I was just shocked to see the commented private replaced with public and the private methods being used outside of the class scope. This made me scared about the project becoming a heap of crutches even before the first release would come out.

Thanks for pointing this out. I've put it back to private. This was most certainly only a debugging measure.

Yves

[yvesdm3000]

The mysterious crashes can be removed from the list for my part. I haven't had a 'mysterious' crash anymore for over a month now... There might still be in the Windows-port but I can't do any user-testing with it using my daily job...

Yves

[yvesdm3000]

For the C++11 requirement please ask the C::B developers. They seem to be open to include this plugin into mainstream so I don't want to bother them with restricting requirements from my part... And even for myself, I need to compile this thing in RHEL5/CentOS5 although I do think I can manage with C++11.

Yves

[l_inc]

yvesdm3000

For me the plugin does not work with a single TU, it switches TU when the associated document is opened.

I was talking about the diagnostics. I've just debugged it a little. And the problem seems to be the GetCurrentTranslationUnitId method, cause it always returns 0. So only the TU that happened to have gotten the m_TranslUnitId == 0 has the diagnostics displayed, which is ensured at the beginning of OnDiagnostics . I removed the if ( m_TranslUnitId == -1 ) condition to always resolve the current TU in GetCurrentTranslationUnitId, and it works OK now.

[yvesdm3000]

yvesdm3000

For me the plugin does not work with a single TU, it switches TU when the associated document is opened.

I was talking about the diagnostics. I've just debugged it a little. And the problem seems to be the GetCurrentTranslationUnitId method, cause it always returns 0. So only the TU that happened to have gotten the m_TranslUnitId == 0 has the diagnostics displayed, which is ensured at the beginning of OnDiagnostics . I removed the if ( m_TranslUnitId == -1 ) condition to always resolve the current TU in GetCurrentTranslationUnitId, and it works OK now.

You seem to have found a bug there. Thanks for sharing !

Yves