https://issues.dlang.org/show_bug.cgi?id=18639
--- Comment #3 from Rainer Schuetze <r.sagita...@gmx.de> --- (In reply to Manu from comment #2) > > - add imports from project dependencies > > Not sure what this means... 'add imports'? You mean dependent project's > source-tree paths so clients can import modules from libs? How do you know a > project's 'root' path? It adds the project path and the import path setting of the referenced project. > > - demangling support > > Is this impossible? Can we bolt-in an output translator to the normal VS > link stage? Not sure this is easy, as replacing the linker executable might have side effects, e.g. with respect to Tracker.exe (the tool that monitors build dependencies). > > > - some special handling for error messages > > What special handling? For example, it can interpret those horrible mixin filenames in error messages. There is also support to interpret stack traces (when running unittests from within Visual D). > > > - integration with compiler generated JSON > > What integration is possible/missing? I don't know if I ever used this with > the old projects...? That info was used by the first intellisense implementation and can still be used as a fallback. It is also used to populate the Object Browser. > > > - better handling of link dependencies > > What can't we do? Can we not just do all the same things that C++ does to > make it all work the same way? See https://issues.dlang.org/show_bug.cgi?id=18642 > > Do you have suggestions for better wording? > > Wording where? I was referring to this remark: > The names need to be clearer in making a distinction between the > MSBuild project, and the old VisualD custom project, and use > language to promote MSBuild as the obvious choice? --