Visual Studio Code code-d serve-d beta release

[Arjan via Digitalmars-d-announce]

On Tuesday, 8 August 2017 at 17:27:30 UTC, Johannes Pfau wrote:
> Am Tue, 08 Aug 2017 17:13:18 +0000
> schrieb WebFreak001 <d.forum at webfreak.org>:
>
>> On Tuesday, 8 August 2017 at 08:03:05 UTC, Arjan wrote:
>> > Small request: could the setting "d.stdlibPath" be inferred 
>> > from the compiler in use? DMD and LDC both have a conf file 
>> > in which the paths are already set.
>> 
>> oh cool I didn't know that, is there a standard path to where 
>> these conf files are though?
>
> The D frontend (and therefore all compilers) already has code 
> to print the import paths. Unfortunately this code is only used 
> when an import is not found:
> ------------------------------------------------------------------
> test.d:1:8: Fehler: module a is in file 'a.d' which cannot be 
> read
>  import a;
>         ^
> import path[0] = /usr/include/d
> import path[1]
> = /opt/gdc/lib/gcc/x86_64-unknown-linux-gnu/4.9.4/include/d
> ------------------------------------------------------------------
>
> It should be trivial though to refactor this code and add a 
> command-line switch to dump the import path. See Module::read 
> in dmodule.c. If Walter opposes adding this to DMD (one more 
> command line switch!) we could probably still add it to GDC 
> glue. This code is all you need:
>
> if (global.path)
> {
>     for (size_t i = 0; i < global.path->dim; i++)
>     {
>         const char *p = (*global.path)[i];
>         fprintf(stderr, "import path[%llu] = %s\n", 
> (ulonglong)i, p);
>     }
> }
>
>
> -- Johannes

Even better!
But when this is rejected,
one could also trigger it by feeding a deliberate wrong file to 
the compiler...
Another option is to build a simple hello.d with the -v flag 
which will reveal the location of the binary the location of the 
config file used and also the import paths and lib paths so it 
seems.