VisualD is using the MS linker, which obviously doesn't demangle D symbols when emitting link errors, but it's a pretty serious usability problem when encountering any link errors. (phobos! >_<) I wonder if we could pipe the linker's output through a processor to detect and demangle D symbols when emitting to the output? It should present the link error text exactly the same as a C++ link error, which shows the demangled name first, followed by the mangled name in parens.
I've added a wrapper for the link step. You might want to try the latest version from https://ci.appveyor.com/project/rainers/visuald (BTW: some msbuild functionality is not rebuilt for V2017 on appveyor).
Oops! Installed and now I get this: 1> Link: 1> Microsoft (R) Incremental Linker Version 14.00.24215.1 1> Copyright (C) Microsoft Corporation. All rights reserved. 1> 1> usage: LINK [options] [files] [@commandfile] 1> 1> options: 1> 1> /ALIGN:# 1> /ALLOWBIND[:NO] 1> /ALLOWISOLATION[:NO] 1> /APPCONTAINER[:NO] 1> /ASSEMBLYDEBUG[:DISABLE] 1> /ASSEMBLYLINKRESOURCE:filename 1> /ASSEMBLYMODULE:filename 1> /ASSEMBLYRESOURCE:filename[,[name][,PRIVATE]] 1> /BASE:{address[,size]|@filename,key} 1> /CLRIMAGETYPE:{IJW|PURE|SAFE|SAFE32BITPREFERRED} 1> /CLRLOADEROPTIMIZATION:{MD|MDH|NONE|SD} 1> /CLRSUPPORTLASTERROR[:{NO|SYSTEMDLL}] 1> /CLRTHREADATTRIBUTE:{MTA|NONE|STA} 1> /CLRUNMANAGEDCODECHECK[:NO] 1> /DEBUG[:{FASTLINK|FULL|NONE}] 1> /DEF:filename 1> /DEFAULTLIB:library 1> /DELAY:{NOBIND|UNLOAD} 1> /DELAYLOAD:dll 1> /DELAYSIGN[:NO] 1> /DLL 1> /DRIVER[:{UPONLY|WDM}] 1> /DYNAMICBASE[:NO] 1> /ENTRY:symbol 1> /ERRORREPORT:{NONE|PROMPT|QUEUE|SEND} 1> /EXPORT:symbol 1> /EXPORTPADMIN[:size] 1> /FASTGENPROFILE[:{COUNTER32|COUNTER64|EXACT|MEMMAX=#|MEMMIN=#|NOEXACT| 1> NOPATH|NOTRACKEH|PATH|PGD=filename|TRACKEH}] 1> /FIXED[:NO] 1> /FORCE[:{MULTIPLE|UNRESOLVED}] 1> /FUNCTIONPADMIN[:size] 1> /GUARD:{CF|NO} 1> /GENPROFILE[:{COUNTER32|COUNTER64|EXACT|MEMMAX=#|MEMMIN=#|NOEXACT| 1> NOPATH|NOTRACKEH|PATH|PGD=filename|TRACKEH}] 1> /HEAP:reserve[,commit] 1> /HIGHENTROPYVA[:NO] 1> /IDLOUT:filename 1> /IGNORE:# 1> /IGNOREIDL 1> /IMPLIB:filename 1> /INCLUDE:symbol 1> /INCREMENTAL[:NO] 1> /INTEGRITYCHECK 1> /KERNEL 1> /KEYCONTAINER:name 1> /KEYFILE:filename 1> /LARGEADDRESSAWARE[:NO] 1> /LIBPATH:dir 1> /LTCG[:{INCREMENTAL|NOSTATUS|OFF|STATUS|}] 1> /MACHINE:{ARM|ARM64|EBC|X64|X86} 1> /MANIFEST[:{EMBED[,ID=#]|NO}] 1> /MANIFESTDEPENDENCY:manifest dependency 1> /MANIFESTFILE:filename 1> /MANIFESTINPUT:filename 1> /MANIFESTUAC[:{NO|UAC fragment}] 1> 1> 1> 1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(638,5): error MSB6006: "pipelink.exe" exited with code 1100. Something went wrong >_<
Trying to build DMD, I get a different error: 2>C:\Program Files (x86)\VisualD\msbuild\dcompile.targets(134,15): error MSB4030: "true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true;true" is an invalid value for the "DebugFull" parameter of the "CompileD" task. The "DebugFull" parameter is of type "System.Boolean".
I also noticed some error dialogs pop-up when I launch VS after installing that build. I didn't take notice of them at the time, I didn't think they were VisualD related, but perhaps they were...
> Trying to build DMD, I get a different error: >2>C:\Program Files (x86)\VisualD\msbuild\dcompile.targets(134,15): error MSB4030: Should be fixed in the new build. >Oops! Installed and now I get this: >1> Link: Hmm, works here. Can you send me the build log with "diagnostic" verbosity?
Emailed you the log (building DMD)
appveyor built with dmd 2.071 which was the last version to produce a broken executable. Now updated to 2.080. Please try the new version.
How was it that DMD produced a broken executable? Is that a thing? That sounds like a critical bug if it's producing subtly broken code.
That was dmd 2.071 from 2016, with rather fresh support for -m32mscoff. I don't think it's worth investigating what the issue was back then. dmd 2.072 produces a working exe.
Haha, out by one! :) Just tried the new one. It works. It still emits the message: 1> pipelink called with: "C:\Program Files (x86)\VisualD\msbuild\pipelink.exe" /ERRORREPORT:PROMPT @C:\Users\maevans\AppData\Local\Temp\tmp120dba8df2854aa59c1d50a0b2e00940.rsp That can probably be turned back off. Awesome work! Thanks again! VisualD is really getting so much better, it's feeling really solid these days. Have you had any thoughts about the /INCREMENTAL linking issue? That's biggest gotcha left that I'm aware of, and I'm using the debugger a lot to debug DMD! MS obviously have a strategy to deal with it in their own debugger.
> That can probably be turned back off. Done. What slightly annoys me is that the wrapper is now also used with C++ builds that have no D source files in them. I haven't seen any issues so far, but the tracker log files are different now and I'm not sure that might has no side-effects.
I also had that thought... but I tried to push it aside and pretend I never thought of it :P
Let's call this done huh?
I think I managed to call pipelink.exe only if there are D sources found in the project itself or any referenced project, similar to adding the runtime libraries.
Oh cool. I suspected it must be possible, exactly because you already do that for the runtime libraries ;)