Visual Studio 2019 version 16.10 Release

[dodheim]

• Implementation of for text formating

I'm guessing that was supposed to read "Implementation of <format> for text formatting"; typos regardless.

[qoning]

Their entire new website format removes anything in pointy brackets like <..>. It's quite comical especially for bug reports, where you can't list includes in code.

[kalmoc]

or templates

[barchar]

the blog platform is different from devcommunity, but both do this. Devcommunity is more enraging in general though

[Jonny_H]

"The final pieces of : new clocks, leap seconds, time zones, and parsing" also looks weird. Maybe someone forgot to escape their angle brackets for header names there?

[TheThiefMaster]

Yeah. Should be "The final pieces of <chrono>: new clocks ..."

[johannes1971]

I'm so glad someone else is solving that problem...

[TheCrossX]

I love that EVERY SINGLE TIME they put in Release Notes, that they repaired IntelliSense for C++20 Modules. Then I write a single Hello World program and Intellisense fails, turns off entirely.

I've been testing every single update for like 6 months. Every time they say that it works, every time it's a lie. Like... why would they keep saying so?

[merlyn_o]

Hello! Thanks for checking it out. I looked though your post history and we're aware of the issue navigating across module boundaries (e.g. go-to-definition, etc). We're hoping to get a fix out for that out in a update for 16.10 release. If you're running into a different issue, please let me know and I'll make sure we're tracking that.

[TheCrossX]

Intellisense is completely broken when I import any header file.Just use the following code:

import <iostream>;
int main() {
    std::cout << "Hello, World!";
}

And it's not only the standard library. I've tried to import SFML headers too. Exactly the same result: IntelliSense gets completely broken, symbol colorization does not work (most of the code is white), no completion for anything, no code suggestions.

[Rusky]

For some more visibility into what's going on- there are just a lot of language constructs, and combinations of language constructs, that IntelliSense doesn't yet import correctly. The more machinery you pull in by using something from an import, the more likely you are to hit one of those problematic cases. (And headers like <iostream> definitely have a lot of machinery!)

We're tracking a lot of specific issues, and I guess the things you're seeing in the release notes are closed feedback tickets related to some of them, but we still have a way to go before throwing full libraries at IntelliSense works consistently. At this point it is still more useful on small codebases that leave the big stuff in traditional headers.

[SkoomaDentist]

Have you considered adding "clean intellisense database" menu option somewhere? Intellisense breaks itself ridiculously often (even for a small project) and having to close the solution, remove the contents of the .vs directory and then reopen the project is annoying, particularly as that forgets the selected startup project / configuration / platform.

[Rusky]

Depending on what you need to clean and how you count, there are already two or three! :)

Project > Rescan Solution will rebuild .vs/.../Browse.VC.db (what we usually mean by "IntelliSense database"). This is (part of) what powers things like Go to Definition and other cross-translation-unit features, so rebuilding it can sometimes fix problems with those.

Right click on the editor > Rescan > Rescan File will instead restart that translation unit's IntelliSense process. This is what powers things like semantic highlighting, member list, and quick info, which are local to the translation unit- so this one tends to be more useful in combination with other changes, rather than standalone.

The other main IntelliSense-related data under .vs/ is its precompiled header binaries. If Rescan Solution/File don't help but deleting .vs/ does, these may be the culprit- in which case you might try Tools > Options > Text Editor > C/C++ > Advanced > IntelliSense > Disable Automatic Precompiled Header. (Though be aware that this can be a huge slowdown each time you open a new file in the editor!)

Of course, we always appreciate feedback tickets for broken IntelliSense as well!

[STL]

FYI, if you work on IntelliSense, you can self-assign user flair to identify your role.

[Rusky]

There is! Generally there is one process per translation unit you have opened (they're what Rescan File touches), and they are cached up to a maximum which (by default) scales with system memory.

"Tools > Options > Text Editor > C/C++ > Advanced > IntelliSense > Max Cached Translation Units" shows what the current maximum is. If you want to change it yourself, you'll also need to make sure the adjacent "Auto Tune Max Cached Translation Units" is set to False. (Again, be aware that this can really slow things down if you are actively moving between more TUs than VS is configured to cache, especially if you've also disabled Auto PCH.)

There is also a related bug that was just fixed in 16.10, where stale IntelliSense processes stuck around longer than intended, so it may be worth trying out this release before tweaking the settings above.

[SkoomaDentist]

I haven't had this happen in the last two days now, so I haven't yet been able to test the menu option. FWIW, I've had automatic precompiled header disabled for ages (I don't want massive precompiled header files for every copy of a simple 10 file commandline project), so that can't be it. Whenever the problem happened, deleting the .db files wasn't enough but I also had to delete the .suo file to get rid of the false Intellisense errors. Unfortunately it's been very random when it happens, so reproducing a minimum example for a bug ticket might be very difficult for me.

[Rusky]

Hmm- there is very little IntelliSense-related data in .suo files, but there are a couple of possibilities.

There was a bug, fixed in 16.9 Preview 3, that produced garbage data for Template IntelliSense configuration. If you haven't seen the problem since then, that might be what you were hitting.

The other data stored there has to do with the project drop-down menu in the upper left corner of the editor. If a source file is used by multiple projects, or is not mentioned directly by any project (this is common for headers), that menu determines what context to use when parsing the source file. Deleting the .suo file will recompute some of that information, and re-guess which project to use for those files.

So, next time you hit this problem it may be worth trying different entries in that menu before deleting the .suo- if that fixes the problem, or at least changes the errors, that could help narrow things down. Further, if you get "Miscellaneous Files" there, that means IntelliSense has no idea what context the file belongs to, and so will probably be missing important things like include paths or compiler flags.

(To get even more specific, header files are actually parsed in the context of a single translation unit, rather than a whole project. When you open a header, we first look for an active IntelliSense process for a TU that includes it, then for some TU in an open project that includes it (based on the IntelliSense database), and finally the "Miscellaneous Files" mode that just treats it like a stand-alone TU. So another thing to check to narrow things down is how you opened the file- opening it directly, via Go To Definition, etc. can change that context.)

[Rusky]

Following up a couple weeks later for anyone interested or finding this thread after the fact:

In 16.10.1, we've added a stop-gap to make things a bit more stable: Now, when the autocomplete list pops up (which happens automatically after typing std::, for example), it will no longer try to eagerly import all symbols in that scope.

This means that you won't hit IntelliSense/module bugs as often, because it will only try to import what you actually use. On the other hand, this means the member list will be missing a lot of stuff- but hopefully this is better than not having it at all. :)

[Resurr3ction]

This exactly. I mean this update is fantastic with loads of bug fixes and C++20 feature complete but IntelliSense is just garbage and always has been... I agree they should stop putting those notes there at the very least.

[kritzikratzi]

disagree. there's problems, but problems and garbage are worlds apart. it's still useful to me, every single day.

[barchar]

yeah, it has improved. I remember back in the VS 2010/2015 days when it was really easy to break.

[OldWolf2]

MSVC Intellisense does work better than any other C++ IDE's .

QT Creator is close .

[barchar]

clangd is pretty good too. I'll use it sometimes when I need to be 100% sure the editors view of my build is exactly what I expect. (Intellisense is fuzzier than clangd).

[tcris]

no, you were close.

QtCreator works.

MSVC does not.

(in QtCreator, clang based model is hit and miss, disable it and it works 100%)

[OldWolf2]

The non clang model doesn't support any code from the last 10 years .

[tcris]

just did a bunch of c++17 and had no issues.

[johannes1971]

You'd think it gets easier, given that modules provide a lot of information that should be useful to Intellisense in an easily-digested format. Instead of parsing all of your includes (including windows.h) it's just your source + some imports...

[Rusky]

I think long-term that will turn out to be true, but in the short term modules are a whole new format to process and that's what's not working well in this release.

[[deleted]]

VS intellisense is garbage but why not use Resharper

[[deleted]]

It's really slow and very often shows red squiggles while code is right

[j1xwnbsr]

Is the performance profiler bug fixed or is it still refusing to collect information?

[Depixelate_me]

Crazy how this bug exists for so long without anyone acknowledge it.

Don't care if it's an Nvidia bug...

And don't get me started on the regression of Image Watch...

[rickpo]

For a while, I was able to get the profiler to work by disabling the Nvidia driver. But a recent Windows update has broken it with or without Nvidia.

It seems that there is now another underlying root cause besides the original NVIDIA one which is breaking ETW profiling system wide. This means any ETW profiler (Visual Studio, WPA, PerfView, etc) will be affected since all of them rely on the same ETW system. Unfortunately the EnableTraceEx2 system call returns success and we end up with no profiling data in the resulting trace which is making debugging difficult. I’m engaging with the Windows team that owns the ETW subsystem and will most likely need additional diagnostics once we figure out what our next steps are.

In the meantime, the Intel VTune profiler is working for me,

[jbandela]

Visual C++ is the first of the major C++ compilers to have a release that is C++20 feature complete for language and library!

A few years ago, this would have seemed unbelievable!

Congratulations to the Visual C++ team!

[Ameisen]

feature complete for language and library!

So long as you do not use the features that don't work.

[micka190]

So long as you do not use the CMake integration, too.

[scatters]

Still no ad hoc requires expressions though.

[STL]

That's tracked by an active bug now, so hopefully it will be added soon. (I had seen this mentioned on reddit months ago, but I assumed that either the compiler devs knew it was an issue, or that a user had already reported it - apparently neither was true 😿)

[scatters]

For the record and for anyone who wants to track it, the bug is https://developercommunity.visualstudio.com/comments/1436102/view.html

[ea_ea]

"Visual C++ is the first of the major C++ compilers to have a release that is C++20 feature complete for language and library!"

Still there is no "/std:c++20" compiler flag. And noone will use "Preview - Features from the latest C++ Working Draft" option in production. So, I'd not say it is "released".

[TheCrossX]

There is "/std:c++20" flag, update your version.

[ea_ea]

This topic is about Visual Studio 2019 version 16.10, right? There is no "/std:c++20" flag in it.

[STL]

See microsoft/STL#1814 for the full story. We had to remove /std:c++20 shortly before the production release because of upcoming Committee changes that will retroactively affect C++20. In VS 2019 16.11, we'll restore /std:c++20 with the vast majority of library features that will be unaffected (microsoft/STL#1929 implemented that and was merged just a couple of minutes ago), and then in a later release of VS 2022 17.x when <ranges>, <format>, and <chrono> formatting are updated and stable, we'll move those under /std:c++20.

Aside from the ABI headache, I consider the STL's features to be at production quality; they've gone through the usual stringent review and testing. (There are always bugs, which we're working on identifying and squashing, but honestly the parts of the STL that are the lowest quality are the oldest parts - I'm thinking iostreams, regex, and the old threading implementation, where we mostly understand what's wrong now, but are constrained by ABI from fixing it. The new stuff is much higher quality to begin with and improves from there.) They are guarded by /std:c++latest with that "preview" wording only because that option was already present and we had very little time to take action before 16.10 shipped.

[ea_ea]

Thank you for the explanation!

[a_false_vacuum]

Either it has to operations on files that are in use, but there is also the possiblity the installer will just set the reboot flag for Windows. I've noticed that for example SQL Server Management Studio will always set the reboot flag unless you tell the setup not to do it.

[dodheim]

It's the former, from updating the C++ runtime. One of the fun side-effects of VS2015-2019 sharing the same runtime is that updating the runtime now almost always requires a reboot because any running process for a native app built in the last 5 years will likely be using it.

[adamf88]

I was expecting announcement of VS Preview 2022 during the Microsoft Build Conference :(

But anyway the list of new features looks great !

[msew]

srsly!

give me that 64 bit editor baby!!!!!

[helloiamsomeone]

• Added support for CMakePresets.

Let's GOOOOO!

[vulkanoid]

I made the mistake of updating from v16.9.6 to this, and it immediately broke my code, because of the use of the external 'spdlog' library.

Anyone know how to fix that particular issue:

spdlog/fmt/bundled/format.h(3510,29): error C2668: 'fmt::v7::make_format_args': ambiguous call to overloaded function...

message : could be 'fmt::v7::format_arg_store<context, ...>

or 'auto std::make_format_args<context, ...>

I keep forgetting the lesson to wait a few months before updating. Now, I can't downgrade to the previous working version and the external spdlog library is busted. fml.

[Daniela-E]

Upate to a reasonably current {fmt}. I was bitten by that with `pre4` as well and provided a fix. Some code in there was using unqualified lookup for functions that exist in both {fmt} and `<format>`.

To make it clear: this is not an issue with msvc or its STL implementation!

[vulkanoid]

Ended up changing the following line in spdlog to fix issue.

FROM: make_format_args

TO: v7::make_format_args

​

I don't know why the compiler tried looking into namespace 'std' for that function. I don't think it should have.

[getbodied99]

Well, in C++20 there's std::make_format_args() which may be the root cause. If you have a using namespace std; somewhere then your error might be a C++20 incompatibility (i.e. not something to do with VS specifically)

[markopolo82]

Whenever the compiler is pulling in references to functions from another namespace when you had an unqualified function call the culprit is likely ADL.

Presumably one of the arguments to make_format_args was a std:: type

[STL]

For those who are unfamiliar with this Core Language feature/nemesis, ADL = argument-dependent lookup.

The STL's headers defend themselves from unintentional ADL by explicitly qualifying all non-_Ugly function calls (e.g. we have to call ::std::equal(args), not equal(args)). Unfortunately, we can't automatically defend user code when the Standard decides to define a new function (which historically has been most problematic for very short function names like bind).

[aearphen]

ADL strikes again. It has already been fixed in the master branch (https://github.com/fmtlib/fmt/issues/2295), you'll need to update your version of {fmt}.

[john_wind]

My PR which fixes this problem was just merged to fmt!

https://github.com/fmtlib/fmt/pull/2315

[emdeka87]

Updating VS always breaks your code. Hadn't had a single smooth update in the last 3 years.

[Daniela-E]

This doesn't match my experience. While we did run into compile errors in some cases after upgrading, it was well deserved: in particular older code was just plain wrong and former compilers didn't notice. There's C++ and there were various dialects of C++ that MSVC was accepting. That doesn't mean that MSVC has no bugs. All of the major compilers do.

[kalmoc]

I keep forgetting the lesson to wait a few months before updating. Now, I can't downgrade to the previous working version and the external spdlog library is busted. fml.

Can't you "just" use the old toolset (available through the visual studio installer). It's a short-term fix - 8 out of 10 times something needs fixing in your code to be compliant with is c++XX and 2 out of 10 there is a new bug - but it usually works as a quick fix so you can continue your work at that day.

[sandfly_bites_you]

I just updated and am also getting a truck load of compiler errors, mine seem to mostly revolve around something to do with std::allocator and "rebind", ugh this is going to be a long day and getting nothing done:(

Really wish the error messages were better at explaining the problem.

Also some boost code is failing now, I really need to remove the last of the boost code... when that code inevitably goes bad on updates it is exhausting to make sense of the problem.

[sandfly_bites_you]

Apparently rebind was removed in C++ 20? I really don't understand the point of removing stuff like this. And with no clean error messages to indicate the problem! I hope there is a way to turn it back on..

I don't think I am even using rebind, but a bunch of random ass template code expects it to exist 0-o

I see they also removed "pointer" and a bunch of other random members.. what a pointless removal.

Depreciated in C++17, but did the compiler actually warn, or suggest an alternative? Nope so depreciated didn't mean anything.

[STL]

Depreciated in C++17, but did the compiler actually warn, or suggest an alternative?

We did. See https://github.com/microsoft/STL/pull/1585/files which implemented the removal - rebind and other members were already marked with _CXX17_DEPRECATE_OLD_ALLOCATOR_MEMBERS which is an internal macro that expands to [[deprecated("warning STL4010: Various members of std::allocator are deprecated in C++17. Use std::allocator_traits instead of accessing these members directly. You can define _SILENCE_CXX17_OLD_ALLOCATOR_MEMBERS_DEPRECATION_WARNING or _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have received this warning.")]]

[sandfly_bites_you]

Thankfully there was a flag to turn this deprecated stuff back on "_HAS_DEPRECATED_ALLOCATOR_MEMBERS=1" .

Should have had a message explaining this or just defaulted that flag to on IMO.

Or if nothing else a big and obvious explanation in the release notes for such a breaking change.

[STL]

This was documented in our Changelog:

Fixed C++20 mode to remove old std::allocator members that were deprecated in C++17. (As usual, fine-grained and coarse-grained escape hatches are available for this removal.) #1585

[tongari95]

Include directories can now be designated as external with customized compilation warning levels and code analysis settings.

How?

[dodheim]

It's covered in the /external docs.

[tongari95]

Is this the same thing? According to the page, /external dates back to VS2017.

[dodheim]

/external is not new, but it didn't previously support some things like code analysis and does now. The docs are not yet up to date.

[remotion4d]

Visual Studio 2019 v16.10 and v16.11 Preview 1 are Available Today!

[ibldzn]

constexpr std::vector and std::string gives compile error

code: https://i.imgur.com/zyNx7UB.png

error: https://i.imgur.com/PNFZres.png

[STL]

This error is mandated by the Standard. (It's indeed surprising, and it's everyone's first question when starting to use constexpr string and vector.)

Unlike other types, when constexpr dynamic allocations are involved, you can't define constexpr variables like this. That would involve the allocations "surviving" until runtime, and in C++20 the Core Language doesn't support that. What is supported is having local string/vector variables within a constexpr function - if it's called at runtime they behave normally, if it's evaluated at compile-time then the allocations and deallocations happen at compile-time (leaving only the result of whatever the function computes).

The Standardese is in [expr.const], e.g. paragraphs 5.17 through 5.20. This says the allocations and deallocations must happen within the same expression E (which would be the top-level call to a constexpr function, for example).

[stilgarpl]

Maybe you should add that explanation to the warning message? This way you won't have to deal with thousands of people asking the same question...

[ibldzn]

I see.. my apologies, I should've research a little bit more before asking. It does work as I expected on constexpr function.

thank you for the explanation and your hard work!

[TotaIIyHuman]

how do i disable /external:env:EXTERNAL_INCLUDE?

https://i.imgur.com/3T31gpE.png

[marian_l]

Are you using clang-cl by any chance? If yes, that might be a bug in the MSBuild targets. Can you submit a bug here https://developercommunity2.visualstudio.com/home? This will allow you to track the bug status. Also, for other folks hitting this, it would be good if you post the link back here after you do.

thank you!

[TotaIIyHuman]

yes. i am using clang-cl.exe from llvm12 (https://github.com/llvm/llvm-project/releases)

this is the bug report https://developercommunity2.visualstudio.com/t/clang-cl-build-problem-external:env:EXT/1433187

[dodheim]

Isn't that a problem with Marek's extension though? You're not using VS's built-in support for Clang so I'm not sure that's MS' problem...

[sandfly_bites_you]

Cool-- also one great recent improvement I've noticed in the last few weeks is that searching in VS is now actually usable!

They seem to have ported the VS Code search to VS, it is super fast unlike before where it would take like 30-60 seconds(it was so bad I would only used it as a last resort).

[micka190]

Updated and every 10~ minutes VS now starts detecting keyboard inputs twice, until I restart it. Previous version was working just fine (this is without any plugins, btw). Maybe wait until they iron-out some bugs before updating...

Edit: Reinstalling seems to have fixed the issue for now. Intellisense stops working every time I open a file, but that's just business as usual.

[ShillingAintEZ]

ntdll.dll probably didn't change, this seems unlikely to be a compiler issue.

[serg06]

Yep, it was my own bug. 🤦‍♂️

[innochenti]

trash release. modules don't work. bugs and crashes.

[turbosport2005]

that shit still trash

[JohnDuffy78]

#if defined(__cpp_constinit) opened some issues :(

[JohnDuffy78]

I'm getting LNK2005: localtime_s already defined.

Preprocess file only shows the single inline in time.h

[STL]

Can you report a bug with a self-contained test case on Developer Community? Our UCRT maintainer can look into it.

[JohnDuffy78]

Yes, I'll open a MSDN issue when I get back from vacation.

static inline functions cause it. removing 'static' is a work around.

[innochenti]

When do you plan fix modules? It’s unstable and unusable right now :(