As announced two days ago by S. Somasegar and Jason Zander, the Visual Studio 2010 Service Pack 1 Beta is now ready for download! Service Pack 1 Beta comes with a “go live” license which means you can start using the product for production related work (see the license agreement with the product for more details).
With this service pack we’re not only addressing product issues but also improving our underlying libraries and toolset. Specifically we’re enabling the following:
Your feedback on this release will help us improve the final release. Please report any issues you come across in the SP1 Beta to Visual Studio Connect. Once you've had a chance to use Visual Studio 2010 Service Pack 1, please also give us your feedback by taking the Service Pack 1 Beta Survey. The results from this survey inform our work so we build an even better SP1 RTM.
Enjoy! The Visual C++ Team
Is there a list of fixed bugs somewhere? The "What's New in Visual Studio Service Pack 1" help document is incredibly light on details.
Any improvements to the C++0x support? Being able to use variadic templates like I can in GCC would be awesome.
How about the bugs in C++0x lambdas? I understand that we won't see any *new* C++0x features in a service pack (a bit of a shame, and a strategy that feels a bit like something out of the mid-90s, but never mind that), but will bugs in existing C++0x features have a chance of being fixed?
And while AVX intrinsics are nice, has anything happened to the fairly miserable code generation for SSE intrinsics? (or, if you have no plans to take SSE code gen seriously, how about at least re-enabling inline asm for 64-bit builds? I totally understand (and agree) that it should be unnecessary and intrinsics preferable in a perfect world, but at the moment, your compiler just isn't good enough for that.)
can we have the bugs fixed related to VC++ not being able to find certain local variables declared inside case blocks in the debug watch window etc? That is really hurting my productivity.
That, and a non-cleartype rendering mode for the editor.
(I suspect that the blog software will freak out if I post a bunch of links, so perform the obvious transformation to "connect DOT microsoft DOT com".)
> Is there a list of fixed bugs somewhere?
The VC10 SP1 Beta contains fixes for 3 STL bugs. We currently aren't aware of any other STL bugs that are sufficiently severe to be fixed between VC10 SP1 Beta and VC10 SP1 RTW. (That's a good thing, by the way.)
STL bug #1: "vector::erase returns incompatible iterator in debug build"
connect DOT microsoft DOT com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=545013
This regression from VC9 SP1 to VC10 RTM was reported by a zillion people. We broke the iterator returned by vector<T>::erase(first, last). The erase() itself was unaffected, but any attempt to use the returned iterator would trigger a spurious assertion in debug mode.
Although release mode was unaffected, this was fixed because it was a regression, a zillion people reported it, the spurious assertion was very disruptive, and our debug assertions are supposed to be 100% accurate - every time they're triggered, they should be detecting a bug in user code. (The phrasing of the debug assertion dialog makes it sound like the Visual C++ Libraries are complaining about a bug in the STL, which is the exact opposite of what should be the truth. I'm hoping that I'll get a chance to improve this in VC11.)
STL bug #2: "VC10 <algorithm> : Incorrect result from is_sorted_until"
connect DOT microsoft DOT com/VisualStudioJapan/feedback/ViewFeedback.aspx?FeedbackID=560807
is_sorted_until(), a C++0x algorithm that was added to VC10 RTM, was implemented incorrectly. (is_sorted(), also new to C++0x/VC10 RTM, was fortunately unaffected.) Although this wasn't a regression (it was a bug in a new feature), it was fixed because the incorrect return value could lead to silent bad behavior at runtime. (Errors at compile time, though obnoxious, are much less harmful.)
STL bug #3: "inserting in a std::vector of std::string causes memory leak"
connect DOT microsoft DOT com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=564917
This was a regression from VC9 SP1 to VC10 RTM. Despite the title, vector was not at fault here; vector<string> was one of several ways to trigger this. When we added move semantics (which is ordinarily simple) to std::string, it interacted badly with our Small String Optimization. As a result, certain uses of std::string leaked 16-byte chunks of memory. This was obviously fixed because memory leaks in the STL are unthinkably bad. (We're very lucky that this was reported to us quickly and clearly.)
Aside from the STL, we fixed a bunch of Connect bugs in VC. This list may not be exhaustive but I believe it's close:
"Crash while declairing C++ enum"
connect DOT microsoft DOT com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=537956
"Compiler crashes with decltype(*this)."
connect DOT microsoft DOT com/VisualStudioJapan/feedback/ViewFeedback.aspx?FeedbackID=533849
"C++ compiler generates incorrect movups instructions iso movss"
connect DOT microsoft DOT com/VisualStudio/feedback/details/548432/c-compiler-generates-incorrect-movups-instructions-iso-movss
"Optimizer bug (/Og) with the 64-bit 2010 Beta 2 compiler."
connect DOT microsoft DOT com/VisualStudio/feedback/details/512552/optimizer-bug-og-with-the-64-bit-2010-beta-2-compiler
"Bug in x64 C++ compiler (optimizer)"
connect DOT microsoft DOT com/VisualStudio/feedback/details/525943/bug-in-x64-c-compiler-optimizer
"missing destructor calls when optimization is enabled"
connect DOT microsoft DOT com/VisualStudio/feedback/details/336316/missing-destructor-calls-when-optimization-is-enabled
"Class member autocompletion forces wrong member."
connect DOT microsoft DOT com/VisualStudio/feedback/details/548891/class-member-autocompletion-forces-wrong-member
"Crash of visual studio 2010 with a C/C++ project, when hiding/showing all files of solution"
connect DOT microsoft DOT com/VisualStudio/feedback/details/557948/crash-of-visual-studio-2010-with-a-c-c-project-when-hiding-showing-all-files-of-solution
"Reproducible crash when commenting"
connect DOT microsoft DOT com/VisualStudio/feedback/details/573230/reproducible-crash-when-commenting
"[VC2010] Alignment issue with _mm256_store_si256() AVX intrinsic in 64-bit debug builds"
connect DOT microsoft DOT com/VisualStudio/feedback/details/612671/-vc2010-alignment-issue-with-mm256-store-si256-avx-intrinsic-in-64-bit-debug-builds
We also fixed a bunch of non-Connect bugs in VC (found by ourselves, reported to us by other Microsoft teams, or reported to us by external customers through their support channels). I'll see if I can get permission to post my nearly-exhaustive list. I know I can post one of them, because I figured out the self-contained repro after an initial report from another Microsoft team:
DevDiv#65309 "[Dev10 SP1]: Lambdas and precompiled headers don't play well together"
This bug had really tricky symptoms and an exceedingly simple cause. The title says what the problem was (I take pride in writing clear bug titles): lambdas in precompiled headers sometimes (but not always!) triggered bizarre compiler errors. When the compiler sees a lambda expression, it has to generate a function object class, and construct an object of that class. The class needs a unique name, so the compiler used `anonymous-namespace'::<lambda0> for the first lambda encountered, then lambda1, lambda2, and so forth. When creating a precompiled header, the compiler literally snapshots its brain (i.e. memory) to disk, and then reloads it when the PCH is used. The problem was that we forgot to snapshot this lambda counter. Therefore, lambdas in a PCH would be named lambda0, lambda1, lambda2, etc. and then lambdas in a source file (after loading that PCH) would also be named lambda0, lambda1, lambda2, etc. This wasn't supposed to happen, and could trigger ambiguities. The fix in VC10 SP1 (it's different in VC11) is to snapshot the lambda counter as part of the PCH, so that the count doesn't restart at 0.
Unfortunately, we *don't* have a master list sitting around - I've obtained this information by digging through VC's source control history (i.e. looking at the VC10 SP1 branch). I can't do the same thing for all of VS, which is way bigger than VC.
> Any improvements to the C++0x support? Being able to use variadic templates like I can in GCC would be awesome.
Sorry, no new C++0x compiler/library features in VC10 SP1. (Nobody wants variadic templates more than I do!)
> How about the bugs in C++0x lambdas?
The lambda/PCH bug was fixed, see above. The other bugs you're referring to are probably caused by the difference between lambdas v1.0 and lambdas v1.1. (The Standardization Committee updated the specification for lambdas, clarifying many things for implementers, but it didn't happen soon enough for VC10 RTM.) Unfortunately, lambdas v1.1 requires significant changes, so it's not in VC10 SP1.
> will bugs in existing C++0x features have a chance of being fixed?
If they're sufficiently severe. Report them NOW (like, open up Connect this very minute) if you want something to be considered for VC10 SP1 RTW.
Great list Stephan! Where there any MFC bugs? I'm interested in connect DOT microsoft DOT com/VisualStudio/feedback/details/611434/access-violation-in-afxcustomizemenubutton-cpp
Nothing for me, a poor coder that uses C++/CLI a lot .... sigh
Cannot install. "A compatible version of Visual Studio 2010 was not detected on the system. This update is designed for only the Microsoft Visual Studio 2010."
I have a French version of VS2010 installed. Perhaps, that is the reason of the incompatibility... Will there be a French beta or will I have to wait for the final release ?
VS2010 was released with this unusable (at least for me) help viewer. Then, you come with a service pack which "re-introduces key productivity features including a fully-expandable table of contents and a keyword index" and sell that as a great new improvement. It's not an improvement at all. It's returning to normal! Hopefully you can return to normal with other features that "by design" were left out of VS2010.
+1 for FRED.
For me it's also very annoying when debugger cant find values in switch statment
What's about Office 2010 Visual Manager? Will it be part of the Service Pack?
Any of the Concurrency runtime issues addressed? Spefically, bug ID:624144.
Marius, at least you're getting your feature back! This announcement is the final nail in the coffin for our use of C++/CLI. I was mildly optimistic that they'd give us our Intellisense back when Boris Jabes [MSFT] made this comment last month:
"First of all, when it comes to C++/CLI we definitely messed up. We simply underestimated the cost of getting our new IntelliSense engine to handle the language extensions in time for VS2010 but we are working on it as we speak and we will rectify that missed feature."
...yet it clearly didn't make the cut, once again. The C++ team keeps swearing that I'm not a second-class citizen, but it sure feels that way sometimes.
Awesome list, I appreciate it. Do you know if a comprehensive list of bugs for all of VC or all of VS will be given in release notes? Or will it be up to us to figure out of if the issues important to us were fixed?
One of the biggest ones for us personally is the speed of the Command Window (or the find box when prefixing your entry with a >). for example, create a huge project with lots of files, and then try to type > open Foo.cpp. Each keystroke can take 3-5 seconds to appear.
> We also fixed a bunch of non-Connect bugs in VC
> I'll see if I can get permission to post my nearly-exhaustive list.
Sorry, I can't post this info, at least not in the form that I have (a data dump of bug titles).
> I'm interested in connect DOT microsoft DOT com/VisualStudio/feedback/details/611434/access-violation-in-afxcustomizemenubutton-cpp
I don't believe that I missed any Connect bugs. (I can't say this with absolute certainty because I had to dig through a bunch of checkins and their associated bugs, and figure out which ones came from Connect.)
> Any of the Concurrency runtime issues addressed? Spefically, bug ID:624144.
Looks like that Connect bug was duped against an earlier non-Connect bug. (I am surprised that this is even possible in our bug tracking system, as it prevents customers from figuring out what happens to the bug that they took the time to file.) The primary bug is still being investigated for VC11, so it's safe to say that it isn't fixed in VC10 SP1 Beta.
> Do you know if a comprehensive list of bugs for all of VC or all of VS will be given in release notes?
I've been informed that this will happen for fixes tracked by KB articles. Other fixes, both Connect and non-Connect, don't benefit from the same process. There's a meeting next week where we'll bring up this issue.
> One of the biggest ones for us personally is the speed of the Command Window (or the find box when prefixing your entry with a >).
> for example, create a huge project with lots of files, and then try to type > open Foo.cpp. Each keystroke can take 3-5 seconds to appear.
Did you file a Connect bug about this? Hoping that someone else notices a bug you care about isn't especially reliable. :->