When will Code::Blocks support "noexcept" specifier?

[Yamakuzure]

Hello everybody,

are there any plans known when C::B (SVN 9425 on Gentoo Linux) will support the "noexcept" specifier? Currently it is like this:

1. Right Click -> Insert -> All class methods without implementation
In this case all methods with noexcept specifier are automatically selected, even if they already have an implementation. And the implementation template then is inserted without "noexcept".

2. Toolbars -> Code completion
All methods / functions with "noexcept" are missing here.

Thanks in advance!

Reference: C++11 noexcept specifier and C++11 noexcept operator.

[Yamakuzure]

Bug 19188 opened, as there are either no plans, yet, or none known.

[Alpha]

Our parser for codecompletion does not handle C++11 constructs (or templates) very well currently.  There are plans to eventually incorporate Clang, which would bring full support for C++11, however there is no estimated timeline.

[ollydbg]

Maybe, adding such keyword handling in current CC's parser is not that hard (mainly in ParserThread class). So, patches are welcome. 
(I'm just a little busy on other things of C::B.)

[Yamakuzure]

Our parser for codecompletion does not handle C++11 constructs (or templates) very well currently.  There are plans to eventually incorporate Clang, which would bring full support for C++11, however there is no estimated timeline.

What does the C language family frontend for LLVM have to do with this? I'm just curious.

Maybe, adding such keyword handling in current CC's parser is not that hard (mainly in ParserThread class). So, patches are welcome. 
(I'm just a little busy on other things of C::B.)

Ok.

http://pastebin.com/Cj4GmAkb Contains a patch that adds noexcept.
It works for me for the "Insert"->"All class method without implementation..." function.

I have not yet further tested it, as I am at work right now and couldn't spare more than 20 minutes. But from a first glance it seems to re-enable the filling of the code completion dropdown widget, too.

[Alpha]

Our parser for codecompletion does not handle C++11 constructs (or templates) very well currently.  There are plans to eventually incorporate Clang, which would bring full support for C++11, however there is no estimated timeline.

What does the C language family frontend for LLVM have to do with this? I'm just curious.

It means that in about a thousand lines of code, there is fully functional codecompletion that gives results of greater accuracy than our current CC plugin (which has over 20 thousand lines of code).
Using the frontend from a fully functioning compiler gives the benefit of all the precise knowledge the compiler has about parsing source code.

[Yamakuzure]

Our parser for codecompletion does not handle C++11 constructs (or templates) very well currently.  There are plans to eventually incorporate Clang, which would bring full support for C++11, however there is no estimated timeline.

What does the C language family frontend for LLVM have to do with this? I'm just curious.

It means that in about a thousand lines of code, there is fully functional codecompletion that gives results of greater accuracy than our current CC plugin (which has over 20 thousand lines of code).
Using the frontend from a fully functioning compiler gives the benefit of all the precise knowledge the compiler has about parsing source code.

So for 1K lines for code completion, one has to install (and on source based distributions like Gentoo Linux compile) the full LLVM and CLANG suites? Sweet.

What do people using Visual C/C++ gain? Is it compatible? What about gcc, icc and such? As far as I understand it, it will only give precise results for LLVM, won't it?

Don't understand me wrong, I really like the idea, I am just yet unable to see how this benefits non-LLVM-users.

[EnterTheNameHere]

I would welcome a mature and refined Lexer/Parser/AST/"Give me tokens and the most information about them you can" tool I can then use to make advanced features like enabling proper CC for variable like following:

Code: c++

auto window = std::make_shared<InterfaceWindow>(); // only example

ATM the only way (I am aware of) to get CC for window variable is to declare it's type:

Code

std::shared_ptr<InterfaceWindow> window = std::make_shared<InterfaceWindow>();

So if
1) Alpha will be able to get it running (fingers crossed)
2) the use of LLVM/CLang will be only to compile Parser plugin for Code::Blocks - it won't be necessary for user to have these in their enviroment
3) Windows!

then the plugin should work for any C/C++/"what CLang language is supported" file, because it only parses the files and gives us AST with all the information about tokens we can then use to make smart Code Completion. The Parser doesn't have to touch user's compiler at all. Although it should ask it for defines.

BTW that's how current CC works too, unfortunately with all it's flaws and "how the hell I'm supposed to implement that without making it worse" features we would like to see in CC - no offense intended, authors did a great job and they even were not paid for it. C++11 (and the following C++14) moved C++ to a new century (I know about C++03, not the point here) and I doubt CC was made minding that in advance (no crystal ball) and now the requirements for CC Parser are enormous - so why not use Parser used by compiler?

If it would work like this, then it's fantastic.

(note: I'm not experienced in parsing/code completion and terminology, so what you've just read is only my understanding of how it works)

[MortenMacFly]

http://pastebin.com/Cj4GmAkb Contains a patch that adds noexcept.

Looks good - committed to SVN, thank you!

[oBFusCATed]

So for 1K lines for code completion, one has to install (and on source based distributions like Gentoo Linux compile) the full LLVM and CLANG suites? Sweet.

On the source based distros you get llvm/clang compiled for you automagically, at least if you're using some smart source based distro.
And by the way the chance that you won't have llvm/clang installed in the future is getting smaller and smaller.

Don't understand me wrong, I really like the idea, I am just yet unable to see how this benefits non-LLVM-users.

You'll have better codecompletion, more precise, supporting the latest standard supported by clang (most of the time well ahead of the competition).
clang is almost compatible to gcc and they are trying to make it compatible to vc++.
C++ parsers build by non-compiler writers are not good in the long term, because they have:
1. missing parts of the standard
2. missing parts of the future standards

With clang or any other compiler that provides and API to its parser you get this for "free".

[Alpha]

During runtime, the clang plugin has two main requirements: access to the libclang binary (.so or .dll) and that the system has standard library headers written in valid (according to Clang's standards) C++.  I recall reading somewhere that Clang can parse the vast majority of MSVC headers (although, this plugin is not yet set up to look for them).  On my computer, it has worked fine using the headers bundled with GCC/MinGW.
The rest of Clang/LLVM is only necessary if a prebuilt libclang is unavailable for the system.

[...] so why not use Parser used by compiler?
If it would work like this, then it's fantastic.

Clang powered CC:

[oBFusCATed]

Can you link to libclang statically?
Otherwise it looks promising.

One question:
Do CC still works for random headers in the source tree, but not in the project?
I love this hidden feature of the current CC plugin. At work we have tons of code
and not all of it is kept in cbp project, so completing random headers or cpps would be great if could be kept.

[Alpha]

Can you link to libclang statically?

The precompiled binaries I downloaded only contain shared libs; I will have to look into seeing if the build system supports static libraries.

Do CC still works for random headers in the source tree, but not in the project?
I love this hidden feature of the current CC plugin. At work we have tons of code
and not all of it is kept in cbp project, so completing random headers or cpps would be great if could be kept.

From my testing, it works approximately as well as the current CC plugin with unbound files.  (This largely depends on how well it is able to find the referenced header files, which seems to be the same as the current CC plugin.)

[Yamakuzure]

First: I now see where this really is beneficial using clang.

And for a bit of on topic: Thank you, MortenMacFly

So for 1K lines for code completion, one has to install (and on source based distributions like Gentoo Linux compile) the full LLVM and CLANG suites? Sweet.

On the source based distros you get llvm/clang compiled for you automagically, at least if you're using some smart source based distro.
And by the way the chance that you won't have llvm/clang installed in the future is getting smaller and smaller.

Yes, unless you have an intel graphics chipset. In that case there is no point to use mesa with LLVM as there is no Gallium3D support for modern intel HD. And apart from mesa there aren't many consumers for LLVM, yet.
Currently, on Gentoo at least, there are:

• dev-lang/ghc : The Glasgow Haskell Compiler
• dev-lang/rubinius : A re-implementation of the Ruby VM designed for speed
• media-libs/mesa : OpenGL-like graphic library for Linux
• sys-devel/sparse : C semantic parser
• app-vim/youcompleteme : vim plugin: a code-completion engine for Vim

That is not much. And I doubt this list is more excessive elsewhere.

However, there is the next part:

Can you link to libclang statically?

The precompiled binaries I downloaded only contain shared libs; I will have to look into seeing if the build system supports static libraries.

Well, the main llvm configure script understands these options:

Code

  --enable-shared         Build a shared library and link tools against it
                          (default is NO)
  --enable-embed-stdcxx   Build a shared library with embedded libstdc++ for
                          Win32 DLL (default is NO)

So as far as I understand it, static linking is the default. Although the second option more sounds like whether or not to statically link libstdc++ into the windows dll, so no static library here (it seems).