{"id":1408,"date":"2018-03-03T12:00:30","date_gmt":"2018-03-03T12:00:30","guid":{"rendered":"http:\/\/dlang.org\/blog\/?p=1408"},"modified":"2021-10-08T11:05:41","modified_gmt":"2021-10-08T11:05:41","slug":"dmd-2-079-0-released","status":"publish","type":"post","link":"https:\/\/dlang.org\/blog\/2018\/03\/03\/dmd-2-079-0-released\/","title":{"rendered":"DMD 2.079.0 Released"},"content":{"rendered":"

\"\"The D Language Foundation is happy to announce version 2.079.0 of DMD, the reference compiler for the D programming language. This latest version is available for download<\/a> in multiple packages. The changelog<\/a> details the changes and bugfixes that were the product of 78 contributors<\/a> for this release.<\/p>\n

It\u2019s not always easy to choose which enhancements or changes from a release to highlight on the blog. What\u2019s important to some will elicit a shrug from others. This time, there’s so much to choose from that my head is spinning. But two in particular stand out as having the potential to result in a significant impact on the D programming experience, especially for those who are new to the language.<\/p>\n

No Visual Studio required<\/h3>\n

Although it has only a small entry<\/a> in the changelog, this is a very big deal for programming in D on Windows: the Microsoft toolchain is no longer required to link 64-bit executables. The previous release<\/a> made things easier by eliminating the need to configure the compiler; it now searches for a Visual Studio or Microsoft Build Tools installation when either -m32mscoff<\/code> or -m64<\/code> are passed on the command line. This release goes much further.<\/p>\n

DMD on Windows now ships with a set of platform libraries built from the MinGW definitions and a wrapper library for the VC 2010 C runtime (the changelog only mentions the installer, but this is all bundled in the zip package as well). When given the -m32mscoff<\/code> or -m64<\/code> flags, if the compiler fails to find a Windows SDK installation (which comes installed with newer versions of Visual Studio \u2013 with older versions it must be installed separately), it will fallback on these libraries. Moreover, the compiler now ships with lld<\/code>, the LLVM linker. If it fails to find the MS linker, this will be used instead (note, however, that the use of this linker is currently considered experimental).<\/p>\n

So the 64-bit and 32-bit COFF output is now an out-of-the-box experience on Windows, as it has always been with the OMF output (-m32<\/code>, which is the default). This should make things a whole lot easier for those coming to D without a C or C++ background on Windows, for some of whom the need to install and configure Visual Studio has been a source of pain.<\/p>\n

Automatically compiled imports<\/h3>\n

Another trigger for some new D users, particularly those coming from a mostly Java background, has been the way imports are handled. Consider the venerable \u2018Hello World\u2019 example:<\/p>\n

import std.stdio;\r\n\r\nvoid main() {\r\n    writeln(\"Hello, World!\");\r\n}<\/pre>\n
Someone coming to D for the first time from a language that automatically compiles imported modules could be forgiven for assuming that\u2019s what\u2019s happening here. Of course, that\u2019s not the case. The std.stdio<\/code> module is part of Phobos, the D standard library<\/a>, which ships with the compiler as a precompiled library. When compiling an executable or shared library, the compiler passes it on to the linker along any generated object files.<\/p>\n
The surprise comes when that same newcomer attempts to compile multiple files, such as:<\/p>\n
\/\/ hellolib.d\r\nmodule hellolib;\r\nimport std.stdio;\r\n\r\nvoid sayHello() {\r\n    writeln(\"Hello!\");\r\n}\r\n\r\n\/\/ hello.d\r\nimport hellolib;\r\n\r\nvoid main() {\r\n    sayHello();\r\n}<\/pre>\n
The common mistake is to do this, which results in a linker error about the missing sayHello<\/code> symbol:<\/p>\n
dmd hello.d<\/pre>\n
D compilers have never considered imported modules for compilation. Only source files passed on the command line are actually compiled. So the proper way to compile the above is like so:<\/p>\n
dmd hello.d hellolib.d<\/pre>\n
The import<\/code> statement informs the compiler which symbols are visible and accessible in the current compilation unit, not which source files should be compiled. In other words, during compilation, the compiler doesn\u2019t care whether imported modules have already been compiled or are intended to be compiled. The user must explicitly pass either all source modules intended for compilation on the command line, or their precompiled object or library files for linking.<\/p>\n
It\u2019s not that adding support for compiling imported modules is impossible. It\u2019s that doing so comes with some configuration issues that are unavoidable thanks to the link step. For example, you don\u2019t want to compile imported modules from libFoo<\/code> when you\u2019re already linking with the libFoo<\/code> static library. This is getting into the realm of build tools, and so the philosophy has been to leave it up to build tools to handle.<\/p>\n
DMD 2.079.0 changes the game<\/a>. Now, the above example can be compiled and linked like so:<\/p>\n
dmd -i hello.d<\/pre>\n
The -i<\/code> switch tells the compiler to treat imported modules as if they were passed on the command line. It can be limited to specific modules or packages by passing a module or package name, and the same can be excluded by preceding the name with a dash, e.g.:<\/p>\n
dmd -i=foo -i=-foo.bar main.d<\/pre>\n
Here, any imported module whose fully-qualified name starts foo<\/code> will be compiled, unless the name starts with foo.bar<\/code>. By default, -i<\/code> means to compile all imported modules except for those from Phobos and DRuntime, i.e.:<\/p>\n
-i=-core -i=-std -i=-etc -i=-object<\/pre>\n
While this is no substitute for a full on build tool, it makes quick tests and programs with no complex configuration requirements much easier to compile.<\/p>\n
The #dbugfix Campaign<\/h3>\n
On a related note, last month I announced the #dbugfix<\/strong> Campaign<\/span><\/a>. The short of it is, if there\u2019s a D Bugzilla issue<\/a> you\u2019d really like to see fixed, tweet the issue number along with #dbugfix<\/strong>, or, if you don\u2019t have a Twitter account or you\u2019d like to have a discussion about the issue, make a post in the General forum<\/a> with the issue number and #dbugfix<\/strong> in the title. The core team will commit to fixing at least two of those issues for a subsequent compiler release.<\/p>\n
Normally, I\u2019ll collect the data for the two months between major compiler releases. For the initial batch, we\u2019re going three months to give people time to get used to it. I anticipated it would be slow to catch on, and it seems I was right. There were a few issues tweeted and posted in the days after the announcement, but then it went quiet. So far, this is what we have:<\/p>\n