Report a bug
If you spot a problem with this page, click here to create a Bugzilla issue.
Improve this page
Quickly fork, edit online, and submit a pull request for this page. Requires a signed-in GitHub account. This works well for small changes. If you'd like to make larger changes you may want to consider using a local clone.

Version 0.3.36

The latest release 0.3.36 of Visual D included a considerable number of bug fixes and improvements (you can find all of them listed in the history), but I'd like to detail on a few bigger highlights.

Unit testing and code coverage

With unittesting built into the D programming language testing your code gets even simpler in combination with Visual D. With the new command "Compile and Run" from the Visual D menu you can compile the current D source file through rdmd which will pick up imported modules automatically and add them to the compilation. If the file is part of a project in the solution the current compiler settings will be used, otherwise the defaults from the !ConsoleApp project template are taken. You can add other options in Visual D's global project settings.

The standard is "-unittest --main" so after successfully building the source file to an executable ("--main" adds an empty main function to the source to automatically create a valid executable), your unit tests will run and you will see the result in the output pane.

[Actually, while writing this text a number of issues have been fixed and improvements have been made, so please try the latest release candidate for next version of Visual D from the download folder (0.3.37rc1 as of now). Especially, it will remove some of the command line options used to call rdmd that make it crash pretty often.]

If you add "-cov" to the command line aswell the executable will be instrumented to record the source code lines that have been executed and will mark the lines that have code generated but are never executed. This information is written into files named as the source files but with extension ".lst". If you enable option "Colorize Coverage" in the Visual D colorizer settings (easily reachable through the new entry in the Visual D menu), these lines will be highlighted in the editor. The highlighting will not show up unless the lst-file is newer than the source file as it will probably be out of sync otherwise.

If you fix the last test and add the line assert(fib(19) == 4181); to the unittest, and run the unittest again, all lines will become green.

If you start editing the source file Visual D will try to keep coverage information in sync. If you want to get rid of the coverage coloring, just resave the source file. Visual D will assume the coverage is invalid then and stop displaying it.

If you don't want syntax highlighting from coverage generated .LST files, you can disable it by unchecking the respective option on the Tools->Options->Text Editor->D->Colorizer page.

If you select code within the editor and issue the command "Compile and Run", only the selected code will be passed to rdmd through the --eval option. This allows to execute just a code snippet like a script and see whether it compiles and how it behaves.

New code completion engine by Alexander Bothe

While Visual D has been running a semantic analysis for about a year now to support code completion and type information in tool tips, I didn't have much time to complete it to support all aspects of the D programming language. It is especially lacking on topics like template instantiation, function overload resolution and unified function call syntax (UFCS). Also, compile time function evaluation (CTFE) is pretty incomplete. Due to its pretty large memory foot print the stop-the-world garbage collector has been interrupting the source code editing to inacceptable degrees, so the analyzer had been moved into a separate process communicating with Visual D as a local COM server.

This also opens the door to easily exchange the semantic analyzer with a different engine, so this is where Alexander Bothe's parsing engine enters the scene, the engine that also powers Mono-D and D-IDE.

Alex has put much more effort into making the semantic analysis complete, and it obviously does it more efficiently. I wrapped the library as a local COM server implementing the same interfaces as Visual D's engine (having to do this in C# was a bit of a downer) and just using a different factory now allows switching between the two. Right now, Visual D's engine is the default, but you can select Alex's engine by enabling the respective checkbox in the Intellisense settings page (there is a new menu entry for faster access). It provides UFCS expansion and also displays DDoc help strings in tool tips.

There is currently work being done on the D front end implemented by DMD to be converted from C++ to D, bringing it within reach of using it as a library for IDEs. This might produce another semantic engine in the future which easily keeps in lock step with the latest compiler updates.

LDC support

LDC, the D compiler built on top of the LLVM compiler infrastructure is getting close to being useful on Windows aswell (at least on Win64 the longest standing blocker exception handling is starting to work). You can grab pre-compiled binaries here: (after extracting to any directory just update the paths specified in LDC2\etc\ldc2.conf). In the Visual D project options, path settings for the three major compilers have been separated to different pages allowing for different import and library paths aswell. The specified install directories are mapped to macros like , so they can be reused in other places of your project configuration. To use LDC by your project, select the compiler with the respective option on the General page of your project's property page.

Please be aware that both LDC for Windows aswell as the Visual D support for it are pretty experimental, so expect some glitches. Known issue: there is no debug information in the built executable that can be used by the VS debugger.


If you ever wondered why Visual D versions are numbered 0.3.x, here is the explanation: Each package to be loaded in Visual Studio 2008 needs to be equipped with a valid identification called a package load key (PLK). This key is generated by Microsoft and includes author and package name aswell as the major and minor version of the package. It is used to authenticate the package to Visual Studio. Unfortunately the PLK generation service is no longer available as it is no more necessary to have a PLK for Visual Studio 2010 or 2012 extensions. Unless I choose to be inconsistent with the registered version and the displayed version, Visual D is stuck at version 0.3.