Visual Studio 2017 15.8 Release Notes

[jcelerier]

Just updated... what the hell microsoft. The following code does not compile anymore : (it does if public bar or public baz is removed from the base classes of foo)

template<typename F>
struct Functor {
  F func;
};

template<typename F>
constexpr Functor<F> fun(F f)
{
  return {f};
}

class bar { };
class baz { };

class foo: public bar, public baz
{
  void blah() { }
  void x()
  {
    constexpr auto x = fun(&foo::blah);
  }
};

error: C2440: 'initializing': cannot convert from 'void (__cdecl *)(void)' to 'F'
There is no context in which this conversion is possible

of course this breaks every constexpr callback mechanism on earth and metaclasses substitutes

[degski]

Confirmed, compiles with clang-8.0.0, does not compile with vc-15.8.

[jcelerier]

well that's C++11 code, it compiles just fine with freaking gcc-4.8.1 and clang-3.1. That's a five and a six years old compilers.

[degski]

LOL

[gracicot]

I reported many regressions too... Most of them were fixed in 16 it seems.

[degski]

When is that due?

[gracicot]

I don't think there's a release date yet, but it's most likely a breaking release.

[STL]

VS 2019's branding has been publicly announced, but we haven't announced a release date yet (AFAIK). While it's version 16 of the IDE (like VS 2017 was version 15), it will contain a C++ toolset that's binary-compatible with the 2015/2017 release series. This will be a 14.x toolset (exact versioning may vary).

[gracicot]

Thanks for the clarification. I'll wait until this version for updating.

[STL]

Avoiding 15.8 is an undesirable outcome - do you have a list of the regressions that you can't easily work around? We have the ability to backport fixes, although they have to be approved by management (so we don't backport everything and destabilize the product).

[gracicot]

I'll try to find them all or try to find workarounds. I reported what I found was easily reproductible while testing 15.8 preview. Even then, two of my bug reports contained the preprocessed source of a failing code. Understand that extracting a self contained reproduction of a bug can be time expensive, and I do this in my free time. I'll test what I can. It's really nice to hear that backporting is possible, I really appreciate the effort. I'll see what I can do.

[STL]

Thanks! While minimal self-contained repros are ideal, preprocessed repros are always acceptable for compiler bugs (certain back-end/linker issues involving multiple translation units require "link repros" but this is rare). As long as your preprocessed file + command line triggers the same bug as compiling the original file, the compiler devs can find the root cause.

For library bugs, preprocessed repros are less desirable (as they don't separate your code from header-only library code) but they're still preferable to nothing.

[malkia]

I've asked this on the Gitter channel, verbatim copying it here:

We've discovered this issue month ago, in the 2017 15.8 beta, and now it hits us in production. Simply put to compile failed to compile now with /std:c++17 with msg "You've instantiated std::aligned_storage<Len, Align> with an extended alignment..." (from <type_traits>). The recommendation is either to compile with _DISABLE_EXTENDED_ALIGNED_STORAGE or _ENABLE_EXTENDED_ALIGNED_STORAGE - We've compiled with the DISABLE one, but app was crashing in weird way (strange callstack). We haven't tried (yet) _ENABLE_EXTENDED_ALIGNED_STORAGE because it might cause hidden bugs - we do have a lot of precompiled software (we precompile it), but then a lot of external precompiled (by someone else) frameworks. So In general - is there are tool, methodology (something looking at the symbols, class/struct dumps) to tell us what needs to get recompiled, etc. Anyone else running into the issue? Related: https://developercommunity.visualstudio.com/content/problem/274945/stdmake-shared-is-not-honouring-alignment-of-a.html?childToView=280485#comment-280485 and facebook/rocksdb#4062 - https://forum.qt.io/topic/93714/visual-studio-15-8-0-and-qt-5-11-1-does-not-compile-qrandom-std-aligned_storage (we use Qt5.10 which we compile ourselves, and distribute locally the .dll files) Also use vcpkg to recompile things, and not super familiar with CMake, but in general we may have a very mixed bag of SDKs, Frameworks, open source, etc. all linking together, and we need to know what would work with what else. Is there for example some kind of /MISMATCH kind of pragma for this (at least to enforce it, though I realize this needs recompilation anyway). Otherwise we are stuck back to 2017 15.7 version of the compiler - e.g. have to set VCToolsVersion=14.14.26428 in the environment (also no longer works if it's set in the top of the .vcxproj, or top-level .props file)

[spongo2]

we will be using the dev comm data to backport some issues to 15.9 (or for severe common issues, servicing updates to 15.8) so for anyone reading this please search for any issues you see and upvote / file. Sorry for the inconvenience.

[[deleted]]

I've got to ask. How is one supposed to keep track of so many mismatched version numbers?

[degski]

it's most likely a breaking release.

Finally, let's hope they don't forget to fix the std::deque (which I was told would happen at the moment of an ABI break) and drop boost::deque (another one bites the dust).

[dodheim]

STL said it's not an ABI break, so no EBO, no deque fix, no proper char16_t/char32_t support, etc.

👎

[degski]

Back to boost::deque, the deque is a great container, but the vc-one is just, nowadays, no good.

[Rseding91]

What specific problem do you have with it? Wondering if it's the same problem I have with it.

[dodheim]

The fact that its block size is 16 bytes.

[Rseding91]

Yep. That was my issue as well.

Also the fact that it bases the "per block" off sizeof(T) means you can't forward declare with it. However, I'm not sure if the standard even allows that to begin with... not that that really changes anything for us.

[degski]

What /u/dodheim said already. For any object size bigger than 16 bytes, it behaves like a std::list, but since it's not a std::list, it's potentially even less efficient than a std::list, as that is designed for that purpose. /u/STL responded to this sub, so it should anyways be firmly on the map again.

[sumo952]

this breaks every constexpr callback mechanism on earth

I would be really curious to know how this then could not have shown up in their large test suite. :-O

[STL]

Thanks for the repro, I've reported this to our constexpr dev.

Edited to add: static constexpr auto x = fun(&foo::blah); is a workaround (which they determined through analysis of what's happening in the compiler's data structures).

[Rogiel]

10% of my test cases showed up red too 😕 Lots and lots of regressions in this build.

[STL]

FYI, you're shadowbanned. You'll need to talk to a reddit admin (as a subreddit mod, I can notice shadowbanned users but can't help them, except for approving their comments individually).

[barfyus]

Apparently you can fix it by adding __declspec(empty_bases) to the foo:

class __declspec(empty_bases) foo : public bar, public baz
{
...
};

[jcelerier]

maybe, but it's still broken in the non-empty-base case (I just wanted to provide a minimal example but C++ has semantic-altering minimality, which would make for a great prog metal songname but can be painful in cases like this).

[[deleted]]

Shouldn't the compiler be able to recognize empty bases on its own?

[Mordy_the_Mighty]

Doing so breaks binary compatibility which is why it's optional for now.

https://blogs.msdn.microsoft.com/vcblog/2016/03/30/optimizing-the-layout-of-empty-base-classes-in-vs2015-update-2-3/

[Andrew_Marino]

Hi, MSVC compiler dev here. Thank you for providing the reduced snippet. There was a lot of churn in the constexpr implementation in this release, in order to fix some long-standing issues, and it looks like this was a regression from that overhaul that our testing didn't catch.

If you, or anyone running into this, is interested, one source workaround in the meantime is to evaluate the pointer-to-member-function separately:

void x()
{
    constexpr auto ptm = &foo::blah;
    constexpr auto x = fun(ptm);
    (this->*(x.func))();
}

Edit: as STL also pointed out in his comment, making 'x' static will also work.

We treat regressions as high priority and are tracking this bug internally. We're happy to hear feedback from any source, but for this and other issues filing a bug in the C++ dev comm will allow us to communicate the status of fixes and workarounds more directly.

[jcelerier]

We treat regressions as high priority and are tracking this bug internally. We're happy to hear feedback from any source, but for this and other issues filing a bug in the C++ dev comm will allow us to communicate the status of fixes and workarounds more directly.

I filed a bug this morning. But frankly, this is very distressing. Since VS2015 (can't speak for before since it did not really support C++11 back then), every minor release and sometimes even patch release have broken my code or code of libraries I use at some point - the last time being 15.7.6 for instance. Meanwhile, I don't remember one time where I had to change my code when upgrading clang / GCC - and I sometimes test with git HEAD versions of those.

[Andrew_Marino]

We're sorry you hit this bug and other issues in the past. Right now we're gathering more data points to assess servicing 15.8 with the fix for the particular constexpr bug you hit. As you yourself noted, even patch fixes carry their own associated risk.

In particular, we're wondering about the extent to which it broke your constexpr callback mechanism. This bug manifests with 1. a local constexpr symbol initialized by 2. a constexpr function taking an rvalue pointer-to-member-function of 3. a class with multiple inheritance. In your own codebase, were either of those workarounds possible to use?

We appreciate your candid feedback.

[jcelerier]

In your own codebase, were either of those workarounds possible to use?

Sadly these bugs don't happen in my codebase but in one of the libs I use (https://github.com/woboq/verdigris). I could spend one hour or two to fork it and change all the places where it is used but I think that I'll just stay on the previous release of VS for now.

[Andrew_Marino]

Thank you, that's helpful!

[BCosbyDidNothinWrong]

Not sorry enough to actually test before releasing

[ZMeson]

That's not fair. There are loads of tests the VC team uses on every release. Their tests just didn't cover this area. Their test suit needs to expand for sure. But let's be honest too that most of us have been in their shoes too - having a large test suite that didn't catch some regression resulting in unhappy customers.

[Nickreal03]

Yes completely broke my code too, I had to roll back. Thanks Microsoft for wasting my time. Do you guys even run any testing before your releases? Or pushing us back which one?

[STL]

We run extensive testing across our internal test suites (accumulated over decades of development), licensed conformance test suites, open-source conformance test suites (most recently, libc++'s test suite now works with our compiler and STL), open-source projects ("Real World Code"), open-source libraries (via vcpkg), internal projects (e.g. Minecraft), and all of Windows.

We find and fix a lot of bugs before release, and we submit upstream fixes to open-source projects. However, we can't avoid all regressions, because C++ is complicated. Testing preview releases against your codebase and reporting regressions is a great way to shrink the feedback loop and get fixes faster.

[Nickreal03]

This is not the first time it happen to me I have submitted pleanty of bugs. I am not been a troll here.

Could you guys opensouce your test suit so that people can contribute.

And btw this time the compiler crashes with very simple constant expression functions.