Hello, I’m Mitchell Slep, a developer on the Visual C++ compiler team. I’m very excited to tell you about a new feature in Visual Studio 2010 - C++ IntelliSense can now display compiler-quality syntax and semantic errors as you browse and edit your code!
We display a wavy underline or “squiggle” in your code at the location of the error. Hovering over the squiggle will show you the error message. We also show the error in the Error List window. The squiggles are great for showing you errors in the code you are currently viewing or editing, whereas the Error List window can help you find problems elsewhere in the translation unit, all without doing a build.
We had two scenarios in mind when designing this feature. One is of course productivity – it’s very convenient to be able to fix errors as they happen instead of waiting to discover them after a build, which can save you a lot of time. We also wanted to improve the experience when IntelliSense doesn’t work. IntelliSense has always been a black box – it often worked well, but if it didn’t, you had no idea why. Now IntelliSense has a powerful feedback mechanism that allows you take corrective action – either by fixing errors in your code or making sure your project is configured correctly.
One decision we had to make when designing this feature was how often to update the errors as you edit your code. If we don’t do it often enough, the errors quickly become out of date and irrelevant. But doing it too often can also lead to irrelevant results, like a squiggle under ‘vect’ while you’re in the middle of typing ‘vector’! We also don’t want to hog your CPU with constant background parsing.
We found that a good balance was to wait for 1 second of idle time after you edit or navigate to a new part of the code before beginning to update the errors. In this case ‘idle’ means that you haven’t typed anything and you haven’t navigated to a different part of the code.
We also experimented with some different designs for what to do with existing errors during the short window of time between when you make an edit and when the newly updated errors are available. For instance, one design we tried was to clear all squiggles on the screen immediately after an edit, and then redraw the new errors when they are available. We also considered a variant of this where we only clear the squiggles on the lines below the location of your edit (since making an edit can generally only affect code appearing after it). These designs have the advantage that you never see a stale squiggle, but in usability studies we found that this produced an annoying flickering affect, and also some confusion as to whether a squiggle disappeared because it was fixed or because it was just temporarily being updated. The design we went with was to leave existing squiggles in place after an edit, and then swap them with the new errors when they are available. This works well since the updates are very fast.
One of the technical challenges with this feature was making it fast. As many of you know, large C++ projects can often take several hours to build. One of the ways we get around this is by having IntelliSense focus on a single translation unit at a time (a translation unit is a .cpp file plus all of its included headers). However, even that didn’t give us the kind of responsiveness we wanted for a live-compilation feature like squiggles.
To get even better performance, we’ve developed some innovate incremental parsing techniques that minimize the amount of code we need to parse. This allows IntelliSense to parse your code much faster than the time it would take to do an actual build (or even the time it would take to compile a single .cpp file). The ideas are simple, but are challenging to implement in a complex, context-sensitive language like C++.
When you first open a file, we parse just enough code to build up a global symbol table, skipping over a lot of code (like function-bodies) that only introduces local symbols. Once we’ve built up the symbol table, we lazily parse the code that we skipped “on-demand”. For instance, we only parse the inside of a function body when you actually view it on the screen. If you make changes inside a function body, we are able to reparse just that function body. Of course, all of this only happens during idle time, as described above. These parsing techniques allow us to show you fast, relevant errors even as you edit large, complex code bases.
If your solution already builds with Visual Studio, you will immediately benefit from having accurate syntax and semantic errors reported by IntelliSense as you browse and edit your code. But this feature is also good news for those of you with external build systems. The IntelliSense errors in the Error List window can guide you towards setting up a solution with accurate IntelliSense. For instance, if you load up a solution configured for an external build system, you might see something like this:
Now you know that you need to adjust your Include Path. Making these tweaks to your solution will dramatically improve the quality of IntelliSense you get with an external build system.
It’s been a lot of fun working on this feature and especially dogfooding it – it’s great not to have to do builds all the time! You can preview this feature in Beta 1 and I look forward to hearing your feedback in the comments.
It would be nice if we could define a custom set of compiler restrictions. For example some of the code also has to compile with the CC78K4 NEC C-Compiler. V2.20 does only allow 30 characters for identifiers for example as well as many more restrictions. Could you add visual guidelines for this kind of restrictions? You could draw a squiggle under the part of the identifier that is too long.
The settings could also be used for custom coding styles.
All sounds good. Can you turn it off? I mean without finding the feacp.dll equivalent and renaming it. Pretty please allow users to do this
Check it out this cool feature that my old team has - c++ squiggles! Read Mitchell Slep's post all about
I have never enjoyed having squiggles. I always find them distracting. I understand that this is a common feature, and I am fine with you implementing it, but I just would like to humbly request that you allow it to be disabled if desired.
I love that feature since I got Visual Assist X. The VS2010 implementation seems to be better yet, so kudos for you!
I agree, Visual Assist X has made me love squiggles. I've been messing around in Beta 1 with lambdas and already ran into an instance where I'm getting squiggles on code that compiles cleanly.
Bugs in software happen, there's no avoiding them; however, can something be done to deal with incorrect squiggles besides waiting for the next patch? Perhaps take the "ignore" feature from spell check and let me ignore that specific error for the remainder of my session. Another possibility is to "auto-ignore" after a clean-compile.
If this is already a feature, please let me know where I can find it.
Intellisense (this include squiggles) on some recent extensions to C++ such as lambda expressions, decltype or static_assert wasn't ready to ship in Beta1. You'll see it in Beta2.
Andre - Extensibility of the compiler is something we'd like to be able to offer some day, but we won't have anything like that in Dev10. Check out Mark Hall's post to learn about our longer term vision. http://blogs.msdn.com/vcblog/archive/2009/01/27/dev10-is-just-the-beginning.aspx
Phil - We've added the ability to turn off IntelliSense, as well as specific IntelliSense features. We have separate options for turning off squiggles as well as IntelliSense errors in the Error List window. Deleting feacp.dll will no longer be necessary.
Mitchell Slep [MSFT]
Is this only available for unmanaged C++, or will it also be available in C++/CLI?
Gary - IntelliSense, including squiggles, will only be available in native C++ code. See the comments in Boris' post for more info on C++/CLI IntelliSense: http://blogs.msdn.com/vcblog/archive/2009/05/27/rebuilding-intellisense.aspx
@Mitchell Slep: I don't think I'm looking for compiler extensibility but rather custom coding styles / Intellisense rules.
The CC78K4 (CC78K2 and CC78K3 is even worse) C-Compiler has several restrictions VC++ doesn't have. C++ comments are not enabled by default, no comma after the last enum literal, identifiers are truncated after 30 characters, only 255 enum literals etc.
I'm looking for an easy way to define such rules in a XML file. This would allow to define compiler restrictions as well as coding styles.
I hope you coordinate with the Visual Assist guys to make sure that this system and Visual Assist can co-exist. VA has been working great for me for years and I hope that I can use it with VS2010.
hopefully visualassist and vs2010 together will give us the ultimate c++ coding experience !!
Funny crowd, these commenters. Instead of commenting on how great it will be to have a better intellisense and upfront error checking, they're too busy making sure they're not going to be annoyed by the changes.
Keep up the great work!
While we aren't able to get into specifics at this time, we do want to let everyone know that Visual Assist X most definitely will support VS2010. We intend to continue providing productivity enhancements for everyone that uses Visual C++. Our current plan includes having a preview release for VS2010 Beta 2.