dls 0.19.2

D Language Server

To use this package, run the following command in your project's root directory:

Manual usage
Put the following dependency into your project's dependences section:

This package provides sub packages which can be used individually:

dls:bootstrap - DLS bootstrap utility

dls:gen - DLS translations generator

dls:i18n - DLS translation utilities

dls:protocol - LSP interfaces implementations

D Language Server



LSP compliance: `3.13`

This is still a work in progress; there might still be bugs and crashes

DLS implements the server side of the Language Server Protocol (LSP) for the D programming language. It doesn't do much itself (yet), and rather uses already available components, and provides an interface to work with the LSP. Current features include:

  • Code completion
  • Going to symbol definition
  • Finding references
  • Symbol renaming
  • Error checking
  • Code formatting (document, range and on-type)
  • Symbol listing (current document and workspace-wide)
  • Symbol highlighting
  • Documentation on hover
  • Random, frustrating crashes

Packages used (the stuff doing the actual hard work):


Some editors may need DLS to be installed manually (don't worry, it's easy).

Some common editors

DLS should work with other editors, although your mileage may vary since it's moslty tested on the ones above. If it's not working with your editor of choice, submit an issue!

Command line options

Some command line options exist to control the behavior of DLS:

  • --stdio: use standard input and output streams for communication
  • --socket=PORT or --tcp=PORT: use a socket connecting on the specified port for communication


You can run dub fetch dls and then dub run dls:bootstrap to install dls. The second command will output a path that will point to the DLS executable. DLS will automatically update itself whenever a new version is out.

Client side configuration

All these keys should be formatted as d.dls.[section].[key] (e.g. d.dls.format.endOfLine).

Section: symbolTypeDefault value
Section: analysisTypeDefault value
Section: formatTypeDefault value
endOfLine"lf" or "cr" or "crlf""lf"
dfmtBraceStyle"allman" or "otbs" or "stroustrup""allman"
dfmtTemplateConstraintStyle"conditionalNewlineIndent" or "conditionalNewline" or "alwaysNewline" or "alwaysNewlineIndent""conditionalNewlineIndent"

Server initialization options

DLS supports a few custom initialization options in the InitializeParams.initializationOptions object sent with the initialize request:

interface InitializationOptions: {
    autoUpdate?: boolean = true;
    preReleaseBuilds?: boolean = false;
    catchErrors?: boolean = false;
    logFile?: string = "";
    capabilities?: {
        hover?: boolean = true;
        completion?: boolean = true;
        definition?: boolean = true;
        typeDefinition?: boolean = true;
        references?: boolean = true;
        documentHighlight?: boolean = true;
        documentSymbol?: boolean = true;
        workspaceSymbol?: boolean = true;
        codeAction?: boolean = true;
        documentFormatting?: boolean = true;
        documentRangeFormatting?: boolean = true;
        documentOnTypeFormatting?: boolean = true;
        rename?: boolean = true;


The server may delegate a few operations to the client-side extension depending on the language client's capabilities. The client should watch these files for the server to work properly:

  • dub.selections.json
  • dub.json
  • dub.sdl
  • *.ini

If the client supports dynamic registration of the workspace/didChangeWatchedFiles method, then the server will automatically register file watching. If the client doesn't support dynamic registration however, the client-side extension will need to manually do it. The server needs to know at least when dub.selections.json files change to properly provide completion support. If dub.json and dub.sdl are also watched, dub.selections.json can be regenerated on demand. Watching *.ini allows DLS to monitor D-Scanner config files, even if the name is changed in the config and isn't dscanner.ini.

Custom messages

Since the LSP defines messages with methods starting in $/ to be implementation dependant, DLS uses $/dls as a prefix for custom messages.

$/dls/upgradeDls/didStartNotificationTranslationParamsSent when the upgrade process starts
$/dls/upgradeDls/didStopNotificationnullSent when the upgrade process stops
$/dls/upgradeDls/didChangeTotalSizeNotificationDlsUpgradeSizeParamsSent during the download, with the total size of the upgrade download
$/dls/upgradeDls/didChangeCurrentSizeNotificationDlsUpgradeSizeParamsSent during the download, with the current size of the upgrade download
$/dls/upgradeDls/didExtractNotificationTranslationParamsSent when the download is finished and the contents are written on the disk
$/dls/upgradeSelections/didStartNotificationTranslationParamsSent when DLS starts upgrading dub.selections.json
$/dls/upgradeSelections/didStopNotificationnullSent when DLS has finished upgrading dub.selections.json
interface TranslationParams {
    tr: string;

interface DlsUpgradeSizeParams extends TranslationParams {
    size: number;



The file i18n/data/translations.json contains localization strings. Adding new strings is straightforward, simply add new entries in the message objects with the locale identifier as key and the translated string as value.

Which branch should be targeted by pull requests ?

Is it work on an upcoming new feature ? Then the master branch should be targeted. Is it a fix for a bug you've encountered ? Then the latest release/v[MAJOR].[MINOR].x branch should be targeted.

  • Laurent Tréguier
Sub packages:
dls:bootstrap, dls:gen, dls:i18n, dls:protocol
dls:bootstrap, dub, dscanner, dcd, dls:protocol, dls:i18n, dfmt
0.26.2 2020-Mar-20
0.26.1 2020-Jan-25
0.26.0 2019-Dec-03
0.25.19 2019-Oct-29
0.25.18 2019-Oct-28
Show all 158 versions
Download Stats:
  • 0 downloads today

  • 1 downloads this week

  • 5 downloads this month

  • 13941 downloads total

Short URL: