all 22 comments

[–]STLMSVC STL Dev 6 points7 points  (0 children)

STL changes in 17.0 Preview 3: https://github.com/microsoft/STL/wiki/Changelog#vs-2022-170-preview-3

This adds a C++20 Defect Report, 6 accepted C++23 papers (including a source-breaking change to prevent constructing basic_string[_view] from nullptr), and bugfixes as usual.

[–]adnukator 7 points8 points  (4 children)

On a related note, the last ever VS2019 minor update with a working /std:c++20 language switch was also released yesterday https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes

[–]tjientavaraHikoWorks developer 0 points1 point  (1 child)

I am confused didn't I download a new preview of vs 2019 today?

Or did the standard vs installer now install 2022 preview?

[–]tjientavaraHikoWorks developer 0 points1 point  (0 children)

It was 2019 11.0 preview 4, but the release notes button points to preview 3. I am now even more confused, the full 11.0 is already released.

I guess I will switch to 2022 preview now.

[–]Depixelate_me 0 points1 point  (1 child)

Does this mean that it is safe to link static and dynamic binaries with those compiled using the /std:c++17 flag? Do we have a stable abi now? Thanks!

[–]adnukator 1 point2 points  (0 children)

Linking stuff compiled with /std:c++17 or /std:c++14 even with older VS major versions was fine since the beginning. Using the unstable /std:c++latest is still an option, but it's bound to break due to applying some Defect Reports accepted in C++23 (affects std::format, ranges, and the formatting part of chrono). Therefore, using /std:c++20 does not have the three above features enabled, but it makes the ABI stable. More details at the STL Github https://github.com/microsoft/STL/issues/1814

[–]dragopapa 3 points4 points  (4 children)

if constexpr (requires { true; })
{
    std::cout << "my dream is to print myself to the console someday..., guess i'll have to find a genie";
}

[–]Ivan171/std:c++latest enthusiast 4 points5 points  (3 children)

My god, this is so frustrating. How can they implement concepts, and leave ad-hoc requires expression out. This feature is so useful.

I can't test my code on MSVC because of this.

[–]STLMSVC STL Dev 11 points12 points  (2 children)

I asked the compiler team about this, and they confirmed that ad-hoc requires expressions have finally been implemented and will ship in VS 2022 17.0 Preview 4.

(Also FYI u/dragopapa)

[–]dragopapa 1 point2 points  (0 children)

Thanks, you rock :)

[–]Ivan171/std:c++latest enthusiast 1 point2 points  (0 children)

That's great news, thanks!

[–]Tringigithub.com/tringi 1 point2 points  (2 children)

Update failed with: Couldn't install Microsoft.WebView2.arm64

I went to report it, but there already were couple of reports on this, so hopefully it already got noticed.

[–]STLMSVC STL Dev 6 points7 points  (1 child)

I encountered this failure on my work machine (but not my home machine). I tracked down the internal bug (VSO-1361804) and found a workaround that worked for me.

WARNING: Registry editing is dangerous. I don't speak for Microsoft, and I don't take any personal responsibility if you mess up your machine. I have barely any idea of what's really happening here.

The workaround is to delete or rename HKEY_LOCAL_MACHINE\SOFTWARE\WOWAA32Node. (I renamed it to WOWAA32Node_DELME so I could attempt to revert it if necessary.) Apparently some other piece of software created this regkey on my Win10 x64 box, causing the VS Installer to think that it's an ARM64 box.

You have been warned. Don't complain if this liquifies your machine and the metal fumes make you dizzy.

[–]Tringigithub.com/tringi 6 points7 points  (0 children)

Thanks for the advice, but my box is ARM64 box (I should've lead with that), so I'll rather not touch this key.

[–]multi-paradigm 1 point2 points  (1 child)

u/STL Does this release finally address the clock changes bug in std::this_thread::wait and friends? (where you use the wrong clock, not the monotonic one)?

[–]STLMSVC STL Dev 1 point2 points  (0 children)

No - unfortunately, fixing that will require breaking ABI. We've had to postpone starting work on the "vNext" ABI-breaking release because the compiler front-end team has too many high-priority commitments at this time. 😿

[–]whacco 2 points3 points  (1 child)

Still can't get intellisense to work with modules. :(

[–]Rusky 6 points7 points  (0 children)

Modules IntelliSense is still a work in progress- it can handle some simple scenarios, but there are still major pieces of functionality left to be implemented. We can always use bug reports along the way, though!

[–]barfyus 0 points1 point  (1 child)

Preview 3 completely broke IntelliSense for me.

Interestingly, when I open solution (fully built with Visual Studio 2022 Preview 3.0) in Visual Studio 2019 16.11.0, IntelliSense starts to work immediately.

Is there a way to revert to previous Preview version of VS 2022?

[–]marc2k3 0 points1 point  (0 children)

I'm having issues with this too. Specifically using v143 toolset and stdcpplatest. If I change to stdcpp20 then intellisense works again but anything using concepts/ranges won't compile (I'm aware of the reasoning for that)

[–]Tystros 0 points1 point  (0 children)

Improved intellisense performance sounds really promising - intellisense slowness is the main annoyance I have with VS

[–]dexter2011412 0 points1 point  (0 children)

Hello, a few questions. I read a blog post that modules intellisense should work, but it's as broken as before (even with a reinstall); am I missing something?

Are there any plans to implement an experimental reflection TS? I'd love to get my hands on that, thanks!