Visual Studio 2015 - Compiler errors.

[EmilioCoronado]

Hi,

Have you tried to compile the core with Visual Studio 2015 ( either 32 or 64 bits ) ?

am getting nasty errors within the compiler it goes to error C1001, and C3203 in some classes of the Typepack variadic libraries

/// Turn a class template or alias template \p C into a Alias Class. template <template class C> struct quote { // Indirection through defer here needed to avoid Core issue 1430 // http://open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1430 template using apply = t_<defer<C, Ts...>>; };

[rpavlik]

oh no - I hadn't recently, had hoped that it would be easier, not harder...

[EmilioCoronado]

Hi, can someone who understand the Typepack library have a look and fix it for visual studio 2015 ?

What's the reason what those complicated libraries has been used to implement a basic wrapper containers ?

Thanks

[rpavlik]

I will take a look at it in a bit. Fortunately that bit is relatively easy to test on its own.

TypePack is instead of using Boost MPL or Fusion: it uses C++11 features to do metaprogramming. I try to keep its usage minimal - the reason it's used in the container wrapper is because the container wrapper is customizable with what features are exposed publicly from the underlying container.

[rpavlik]

OK, I've built just the TypePack unit tests in MSVC14, and found two internal compiler errors, which I've isolated in a small repo here: https://github.com/rpavlik/typepack-msvc14-ice

Not sure if they can be worked around easily (if there's some known bug in C++ support that they're hitting - they build fine in many versions of clang and GCC, as well as MSVC 12), or if Microsoft will need to fix the bug on their end but in either case the isolation should be a good step.

[rpavlik]

(the docs for c1001 mention optimization, but disabling optimization and inlining doesn't fix it.)

[rpavlik]

Hmm, though it's definitely in c2, the backend, not the c1xx the compiler frontend, because it still goes boom with the new-in-update-1 "Clang-with-C2" toolset.

[rpavlik]

Err, I take that back. It compiles fine with the clang/c2 thing. The config change just hadn't "taken".

I'm filing a bug.

[EmilioCoronado]

been there, my feeling is that MSVC might been more strict than GCC with some of the latest C++ features, this C1001 does not really give so much information, where are you filing the bug ?

about the containers , i see the point, actually it makes sense, if this is being used to transfer data between objects that not need to know about their internal structure.

However i would prefer to have this implementation packed on their own components, and the system just get to the wrapper itself with the typepack as external library, not so many developers are familiar with meta-programming, and some people might have different ways to implement that part, by instance going back to boost if this is more familiar.

[rpavlik]

MSVC is just actually less conformant/less complete in its C++11/14 parsing/implementation. (The fact that it builds with clang/c2, which uses the MS codegen but the clang frontend is a pretty good clue here) Filed the issue initially over email to the VC++ team, waiting for a reply to see if that's sufficient or if it should go on MS Connect.

While those are provided for library consumer use, they are intended primarily for internal use: they're not exposed on any "public" APIs (clientkit, pluginkit, or their relatives)

[EmilioCoronado]

ah Ok, i read somewhere that some changes 14 where reinforcing some characteristics on the language, i guess that might break a lot of things.

About the libraries, seeing from this point of view probably looks ok, but not sure if it's correct based on the fact that the whole platform is open and public, might limit the capability to improve the core itself.

[rpavlik]

Yeah, no, I'm pretty confident this isn't a correctness issue - given that clang and gcc in multiple versions handle it fine, as well as the EDG frontend used for intellisense, it's just the C1XX frontend that stumbles.

I guess I don't get what you're asking for in the rest of your question/statement. Template metaprogramming is a powerful tool but also challenging to use. It's not expected that many will directly modify that code, and that's OK: it's still substantially simpler than the code it replaced (boost mpl and fusion), and the current container wrapper code is much cleaner and simpler than earlier iterations, and less error prone than one-off duplicate copies all through the codebase. Unfortunately, all the alternative libraries (to typepack/mpl/fusion) are not suitable for the project because they don't even begin to compile on the latest MSVC, much less MSVC 2013, (and many need very recent clang and gcc as well) hence why TypePack started as/exists as a simplified subset/cousin of Eric Niebler's "meta" (the closest fit to the requirements) retaining similar semantics and design but simplifying and adding MSVC support. In any case, this is a bit off-topic from the internal compiler error in MSVC 2015. While we do want to be able to build there at some point, it's not currently a supported platform for building the core, and I imagine it won't be before Update 2 is released, unless MS gets back to me with a workaround for this ICE. (You can still build against the library with 2015, thanks to the C API)

Can you isolate the C3203 errors to add to the reproduction test case? https://github.com/rpavlik/typepack-msvc14-ice

[EmilioCoronado]

Yes, that's a bit off topic from the compiler error, but is coming along within a more general task on platform code inspection and wider scale adoption exploration.

Thanks you for your support.

[godbyk]

Unfortunately, the compiler bug still exists in Visual Studio 2015 Update 1 as well.

[rpavlik]

Could someone isolate the C3203 errors? The C1001 errors in typepack isolated and reported here https://connect.microsoft.com/VisualStudio/feedback/details/2154536 have fixes checked in, so presumably (hopefully) the fix will be in 2015.2, and I'd like to be able to use 2015.2 for the whole thing.

[rpavlik]

Added the need info label because I don't have any information on the C3203 errors to either trace them down to an OSVR bug (unlikely given that it works on many other compiler frontends), or file an issue with Microsoft Connect to get a fix in the next MSVC like for the other issue.

[rpavlik]

OK, there is now a CTP of Update 2 available - that should include the fix for the C1001 errors: https://www.visualstudio.com/en-us/news/vs2015-update2-vs.aspx would be good to find out if any other issues remained with building in 2015.

Note that TypePack itself is modeled on/a subset of Eric Nieblier's meta which is a part of his range_v3 work, which is apparently being used by the MSVC team as a test case, so chances are good that we'll get something usable with 2015 update 2. Whether we'll get something that can compiile in both 2013 and 2015.2, I don't know, but testing and bug reporting (to Microsoft) is the best way to attempt that.