[lld] Enable Visual Studio compatible output

[chrisjackson]

Summary

Adds diagnostic output functions to enable Visual Studio
compatibility with the flag --vs-diagnostics. Clang has a
flag which enables similar support, see
"-fdiagnostics-format=clang/msvc/vi" described
in https://clang.llvm.org/docs/UsersManual.html.
The existing diagnostics output format for warning and error messages is
not fully compatible with Visual Studio (VS) and can even cause VS to become
unresponsive.

The format accepted by VS
(https://msdn.microsoft.com/en-us/library/yxkt8b26.aspx):

{filename (line# [, column#]) | toolname} : [any text] {error | warning}
code####:localizable string [ any text ]

or more simply:

Origin : {warning|error} code#### : Message

The current default lld format uses the lld executable path for Origin.
Clicking the message inside VS will lead to a hang or long delay as VS
attempts to access the executable as a source code origin. Additionally, the
line and column information accepted by VS differs from the lld format.

I've included an additional lit test to ensure diagnostics output in
--vs-diagnostics mode is as expected. All existing lit tests that check
diagnostic output also help ensure that the previous lld output format
is maintained when the flag is not enabled.

[ruiu]

I reviewed this patch, but I'm not convinced that we really want this. You are changing the ELF linker, but how many people are using our ELF linker on Visual Studio? Did you try to talk with Microsoft to let them make a change for you instead of making a change to us? I'm not trying to reject this, but adding a new feature and a new command line flag always needs a fairly strong justification, so please explain how much useful this is.

ELF/Driver.cpp

76–77

This should be moved to ErrorHandlers.cpp.

705–706

This is perhaps too late. This should be processed at the same timing as --color-diagnostics.

ELF/DriverUtils.cpp

135

Why do you need to add this code? If it is working now, you don't need to do this.

ELF/InputFiles.cpp

97

No else after return.

ELF/Relocations.cpp

646

You include Src in an error message and also pass Src to the function. As a result, I believe the same string is printed out more than once. That would look pretty odd.

include/lld/Common/ErrorHandler.h

116–117

I don't like a function with a default argument as it is too easy to mess up. People casually add additional parameters to existing functions, and the result would be a function that has tons of parameters. Please avoid doing this if possible.

[chrisjackson]

ELF/Relocations.cpp

646

Src remains inside Msg so that the output diagnostic message text remains unchanged if --vs-diagnostics is not enabled. It is is also passed as a separate parameter so that it can be used as the origin component of the message when --vs-disagnostics is enabled. This enables the source hyperlink functionality in the VS error list.

[ruiu]

I mean from the user's perspective, showing the same filename more than once seems just odd, no?

[bd1976llvm]

Hi Rui! Thanks for looking at the patch.

Chris is ill so I am replying instead.

In D47540#1116447, @ruiu wrote:

I reviewed this patch, but I'm not convinced that we really want this. You are changing the ELF linker, but how many people are using our ELF linker on Visual Studio?

Surprisingly many! Wikipedia currently lists 1765 planned or released PlayStation(R) 4 games, each of which was built with our elf toolchain.

In D47540#1116447, @ruiu wrote:

Did you try to talk with Microsoft to let them make a change for you instead of making a change to us? I'm not trying to reject this, but adding a new feature and a new command line flag always needs a fairly strong justification, so please explain how much useful this is.

Visual Studio's diagnostic message format is mature and well documented, so although we can propose a change, it seems unlikely that microsoft will implement a change in the near future.

It looks like Chris' patch could be adapted for COFF lld too, with a few changes. Do you think that would be useful?

[chrisjackson]

Thanks for reviewing Rui, I've made the changes as described in my responses to your comments. Primarily:

• removed the extra set of LogName
• made clearer the extraction of the linker executable name from Args
• Made a correction to print() in ErrorHandler
• Removed unnecessary else in inputfiles.cpp

[ruiu]

Could you share a few real examples of error messages with and without this patch to see how they look like?

[chrisjackson]

Updated the lit test to show more examples of the the new error function, in response to a request from Ruiu. Also, corrected the setting of errorHandler.LogName in driverutils as LogName was incorrectly being set even if the --vs-diagnostics flag was not set.

[chrisjackson]

In D47540#1124137, @ruiu wrote:

Could you share a few real examples of error messages with and without this patch to see how they look like?

I've expanded the vs-diagnostics.s lit test with some extra examples to show the
difference in output with and without --vs-diagnostics enabled for several error
call scenarios. I've enumerated the examples so they can be checked against the output
at the end of the message. Currently the errors originate from:

1: 'unrecognised flag' which calls error without a source parameter and arguably shouldn't have this parameter i.e. error(Msg)
2: 'undefined symbol' which uses the new error(Msg, Src) interface and debug line information is available.
3: 'duplicate symbol' which uses an unmodified error(Msg) call and no debug line information is available.

In --vs-diagnostics mode, calling warn()/ error() without the source parameter
defaults the 'Origin' component of the message to the linker executable name
without the .exe extension. This lets the message indicate the originator
of the diagnostic while remaining VS diagnostic format conformant.

I've included the lld output from the lit tests below for comparison as requested. The lit
tests also check that the newline behaviour for multi-line diagnostic messages has
been preserved, by including two undefined symbols in test 1.

Test 1 without --vs-diagnostics

X:\git\upstream\lld_scripts_build\Debug\bin\ld.lld.EXE : error: undefined symbol: flump
>>> referenced by vs-diagnostics.s:1215
>>>               X:\git\upstream\lld_scripts_build\tools\lld\test\ELF\Output\vs-diagnostics.s.tmp.o:(.text+0x1)

X:\git\upstream\lld_scripts_build\Debug\bin\ld.lld.EXE : error: undefined symbol: foo
>>> referenced by vs-diagnostics.s:1066
>>>               X:\git\upstream\lld_scripts_build\tools\lld\test\ELF\Output\vs-diagnostics.s.tmp.o:(.text+0x6)

Test 1 with --vs-diagnostics

vs-diagnostics.s (1215) : error: undefined symbol: flump
>>> referenced by vs-diagnostics.s (1215)
>>>               X:\git\upstream\lld_scripts_build\tools\lld\test\ELF\Output\vs-diagnostics.s.tmp.o:(.text+0x1)

vs-diagnostics.s (1066) : error: undefined symbol: foo
>>> referenced by vs-diagnostics.s (1066)
>>>               X:\git\upstream\lld_scripts_build\tools\lld\test\ELF\Output\vs-diagnostics.s.tmp.o:(.text+0x6)

Test 2 without --vs-diagnostics

X:\git\upstream\lld_scripts_build\Debug\bin\ld.lld.EXE : error: duplicate symbol: wump
>>> defined at vs-diagnostics-multiply-defined.s
>>>            X:\git\upstream\lld_scripts_build\tools\lld\test\ELF\Output\vs-diagnostics.s.tmp2.o:(.text+0x0)
>>> defined at vs-diagnostics-multiply-defined.s
>>>            X:\git\upstream\lld_scripts_build\tools\lld\test\ELF\Output\vs-diagnostics.s.tmp2.o:(.text+0x0)

Test 2 with --vs-diagnostics

ld.lld : error: duplicate symbol: wump
>>> defined at vs-diagnostics-multiply-defined.s
>>>            X:\git\upstream\lld_scripts_build\tools\lld\test\ELF\Output\vs-diagnostics.s.tmp2.o:(.text+0x0)
>>> defined at vs-diagnostics-multiply-defined.s
>>>            X:\git\upstream\lld_scripts_build\tools\lld\test\ELF\Output\vs-diagnostics.s.tmp2.o:(.text+0x0)

Test 3 without --vs-diagnostics

X:\git\upstream\lld_scripts_build\Debug\bin\ld.lld.EXE : error: unknown argument: --nonexistantflag

Test 3 with --vs-diagnostics

ld.lld : error: unknown argument: --nonexistantflag

ELF/Driver.cpp

76–77

This additional set of LogName was unnecessary and is now solely in DriverUtils.cpp ELFOptTable::parse(). Other errorHandler properties are set here too, so I don't know if they should all be moved? I'd be happy to create a common SetupErrorHandler() function that sets the errorhandler properties in one place -- should this be a separate change?

705–706

Agreed. I've moved this.

ELF/DriverUtils.cpp

135

As we need the linker executable name for the diagnostics output, I removed the ArgsArr.slice(1) from LinkerDriver::main, as well as removing this Vec.erase. To make things clearer I've separated the linker name into a separate Stringref that is passed alongside the Argv ArrayRef.

ELF/InputFiles.cpp

97

I've removed the else.

include/lld/Common/ErrorHandler.h

116–117

I left a a default argument so that existing error() and warn() calls needn't be changed. The message output from existing single parameter calls will therefore not be altered by the addition of the VS compatibility mode. I experimented with forcing a message and src parameter but this means every warn() and error() call site must have a source parameter created.

[inglorion]

Common/ErrorHandler.cpp

94

s/paranthesised/parenthesized/

[ruiu]

I noticed that MSVC link.exe doesn't show the error message in such a format that you can jump the source location when a link error occurs. Is this a configuration error in my environment, or is it expected?

[inglorion]

include/lld/Common/ErrorHandler.h

116–117

@ruiu, do you have an alternative proposal? A good number of calls to error() and fatal() have file information, and a good number don't. Unless we want to convert all of those to have file information (what is the file information for an unrecognized command line option?), we need to support both of these cases. There are several ways we could do this, so I'm curious what you have in mind.

[ruiu]

I do not have a concrete proposal at the moment, but before fixing the error reporting interface, I want to make sure that it is as simple and less intrusive as possible. For example, a simple additional text processing to convert Unix-style error message to MSVC style might work (which is a bit hacky but the least intrusive). There are other ideas, perhaps. I'd like to explore more possibilities before setting my mind.

[inglorion]

@chrisjackson,

grep -ER '(error|fatal|warn)\(' lld/ELF

finds a lot of places where we are putting location information in diagnostics. Are you planning to convert those to use the new API/formatting, too?

[chrisjackson]

In D47540#1131841, @inglorion wrote:

@chrisjackson,

grep -ER '(error|fatal|warn)\(' lld/ELF

finds a lot of places where we are putting location information in diagnostics. Are you planning to convert those to use the new API/formatting, too?

@inglorion
I think this presents a choice that could affect the implementation. If all the call sites are converted, then potentially we could make the Src parameter non-optional. However, for the cases where a diagnostic lacks file source information we would risk inconsistent output of the Origin component of the message due to the lack of the optional default. One idea in this case is providing some functionality in the errorHandler class that helps enforce consistency e.g.

error("unknown argument: " + Arg->getSpelling(), errorSrcDefault());

Alternatively, we can convert only some of the calls and retain the optional class for Src. I'm assuming that for simplicity we are only considering options that have a single interface each for error/warn/fatal.

However, the short answer to your question is yes. My preference is to convert all of the diagnostic calls to the new API.

[inglorion]

In D47540#1132106, @chrisjackson wrote:

I think this presents a choice that could affect the implementation. If all the call sites are converted, then potentially we could make the Src parameter non-optional.

Exactly. I think this is a good way to proceed. Making it mandatory to specify an origin should help both communicate that an origin is desired (so that we have a source file in the diagnostic), and also makes it easy to pass that information so that we know how to format it, and harder to do it in an ad-hoc fashion that would not be correctly formatted.

However, for the cases where a diagnostic lacks file source information we would risk inconsistent output of the Origin component of the message due to the lack of the optional default. One idea in this case is providing some functionality in the errorHandler class that helps enforce consistency e.g.

error("unknown argument: " + Arg->getSpelling(), errorSrcDefault());

I've actually always thought that having LogName in ErrorHandler is kind of awkward, and I would love for us to take this opportunity to get rid of it. By the same token, while I think you're right that it is a good idea to have a function to return the string we print, I would like that function to not live in ErrorHandler. Driver may be a good place for it (and is where the LogName is currently determined, too).

I also considered various other alternatives, such as having a more structured API (so e.g. source file and line number are available separately instead of glommed together in a string), but I think it's better to keep it simple for now. We can always get fancier if we find out we need it.

One thing I would have you consider is putting the origin before the message. This doesn't make a super big difference, but it's more consistent with how the code is currently written and the order in which the strings appear.

[chrisjackson]

In D47540#1132711, @inglorion wrote:

One thing I would have you consider is putting the origin before the message. This doesn't make a super big difference, but it's more consistent with how the code is currently written and the order in which the strings appear.

I agree this is the preferred ordering. The only reason message is before origin currently is the use of the optional class.

[chrisjackson]

Common/ErrorHandler.cpp

94

Noted. I'll correct this in a revision some time today. Thanks.

[ruiu]

I created a program that doesn't link and tried to build it on VS. Linker error messages in the VS window are not clickable -- I couldn't jump to the location by clicking a filename and a linename (e.g. foo\bar\baz.cpp:42) in the linker error message. Is this expected?

[chrisjackson]

In D47540#1141831, @ruiu wrote:

I created a program that doesn't link and tried to build it on VS. Linker error messages in the VS window are not clickable -- I couldn't jump to the location by clicking a filename and a linename (e.g. foo\bar\baz.cpp:42) in the linker error message. Is this expected?

@ruiu

Thanks for looking at this. Can you please clarify your experiment e.g. did you use lld in VS or the MSVC linker?
The format of the source "foo\bar\baz.cpp:42" does not meet compatibility for VS diagnostic hyperlinks. There should be no colon and the line and column information should be paranthesized, but you'll see that from my comments and changes.
Thanks,

Chris

[chrisjackson]

• Corrected paranthesised/parenthesized usage in source comments
• Updated the lit test to remove usage of deprecated %T

[ikudrin]

@chrisjackson,

I think we need to see the other places converted, too. Reports for duplicate symbols and invalid relocations will probably require additional changes, which may lead to better design when we see the whole picture.

ELF/InputFiles.cpp

86

You may want to update the comments for InputSectionBase::getSrcMsg().

[chrisjackson]

There are several modifications to the code and lit test additions based
on the suggestions given. The default origin or source used to prefix any
diagnostics with no source code file is now stored in Driver and passed to
ErrorHandler. There are methods to set and get the private member
'DiagnosticSourceDefault'. This is a StringRef initialised to "lld", resembling
the previous behaviour of ErrorHandler.LogName.

Several changes to comments were required to account for the new output
formatting, in InputSection for example. The lit tests have been modified:

• A bad relocation type resulting in an error.
• A bad relocation type resulting in a warning.
• An updated test against a duplicate symbol error.

[chrisjackson]

Added missing relocation test file in ELF/Inputs/

[chrisjackson]

This comment was removed by chrisjackson.

[ruiu]

This still seems a bit too complicated to me. I wonder if we can simplify this by textually tweak error messages inside error() (and other functions such as fatal()), so that error messages are converted to MSVC-ish format, without changing any API.

Since MSVC doesn't recognize multi-line error messages, only the first line of an error message matters. Currently, the first line of an error message is in the following format:

error: filename[:line#]: any text

So it seems easy to recognize this pattern to replace it with:

filename [line#]: error: any text

This might seem a bit hacky, but this is less intrusive than adding a new parameter to all the error-handling functions. What do you think?

[chrisjackson]

I think that if we are to add support for Visual Studio (VS) that any
implementation should be explicit and not rely on quietly attempting to
transform any messages to the desired format. As you suggest, the pattern
matching / transform solution is quite hacky. Also, it will implicitly rely on
the diagnostic message string passed having the properties that the
implementation matches on. If we use a pattern matching implementation, have you
considered how we would handle message strings that do not conform to the
expected pattern?

Clang's Visual Studio format support is not identical to my suggestion but
the output string is constructed for the format and does not rely on a transform
e.g. llvm\tools\clang\lib\Frontend\TextDiagnostic.cpp.

Additionally, I believe that intrusion of extending the api as I've suggested is
outweighed by the structure it will bring to diagnostic messages. Currently any
string can be passed to error/warn/fail and it might be nice to suggest some
kind of consistency by separating the source and message.

[ruiu]

In D47540#1154213, @chrisjackson wrote:

I think that if we are to add support for Visual Studio (VS) that any
implementation should be explicit and not rely on quietly attempting to
transform any messages to the desired format. As you suggest, the pattern
matching / transform solution is quite hacky. Also, it will implicitly rely on
the diagnostic message string passed having the properties that the
implementation matches on. If we use a pattern matching implementation, have you
considered how we would handle message strings that do not conform to the
expected pattern?

I agree with you that what I suggested is hacky, but that's not immediately mean that's a bad approach. We could just pass through error messages that don't match the pattern. I'm not arguing that that's a better approach than extending the error message API, but I believe it's worth thinking.

It also feels to me that the API that takes both a source location and an error message might not nail it. Some error messages don't have the notion of the source location (e.g. command line argument) and some have multiple source locations (e.g. duplicate symbols). Adding a new API that covers only one case feels a bit odd to me.

[ikudrin]

Can we try the approach where the final style of diagnostic messages is determined in the reporting module and all other code just don't care about it?
Right now, we have a bunch of functions here and there which prepare some parts of the message in a specific style. Maybe it will be more semantically clear if there is a distinct place where the resulting message is prepared while all other parts of the linker provide only basic parts of the message (like message text, source location(s), code location(s), etc.) in a structured form. In this case, we can adjust only that distinct place to add any required message styles.

[chrisjackson]

@Ik

In D47540#1157167, @ikudrin wrote:

Can we try the approach where the final style of diagnostic messages is determined in the reporting module and all other code just don't care about it?
Right now, we have a bunch of functions here and there which prepare some parts of the message in a specific style. Maybe it will be more semantically clear if there is a distinct place where the resulting message is prepared while all other parts of the linker provide only basic parts of the message (like message text, source location(s), code location(s), etc.) in a structured form. In this case, we can adjust only that distinct place to add any required message styles.

While more structured, I think this approach could be even more invasive than that suggested. Do you have an example implementation?

@ruiu
Clang has specific visual studio diagnostics format support. Do you think their approach is too involved?

[ikudrin]

In D47540#1176742, @chrisjackson wrote:

While more structured, I think this approach could be even more invasive than that suggested. Do you have an example implementation?

Not yet. I can prepare a patch if no one is against the idea itself.

[ikudrin]

Please see D50560 for my variant.

[chrisjackson]

This work was completed in D58484.

Common/ErrorHandler.cpp

void lld::diagnosticHandler(const DiagnosticInfo &DI) {
   }
 }
 
 void lld::checkError(Error E) {
   handleAllErrors(std::move(E),
                   [&](ErrorInfoBase &EIB) { error(EIB.message()); });
 }
 
-void ErrorHandler::print(StringRef S, raw_ostream::Colors C) {
-  *ErrorOS << LogName << ": ";
-  if (ColorDiagnostics) {
-    ErrorOS->changeColor(C, true);
-    *ErrorOS << S;
-    ErrorOS->resetColor();
+void ErrorHandler::print(const Twine &Msg, const Twine &Origin,
+                         const Twine &LevelText,
+                         const raw_ostream::Colors Color) {
+  newline(ErrorOS, Msg);
+
+  // Visual Studio diagnostics must conform to several formatting rules that
+  // change the output from the default:
+  // - line/column information must be paranthesized.
+  // - Origin provides the source file and line information. While Origin can be
+  //   blank when source information is not available, we default to the lld
+  //   executable name without the path and '.exe. extensions. The current lld
+  //   behaviour is to use the full lld executable path, but visual studio
+  //   interprets this as a path to the source file. Locally we store this as
+  //   LogName, but this is a reference set with Driver->diagnosticSrcDefault().
+  //
+  // For details on the Visual Studio diagnostics format see:
+  // https://blogs.msdn.microsoft.com/msbuild/2006/11/02/msbuild-visual-studio-aware-error-messages-and-message-formats/
+  if (VSDiagnostics) {
+    std::string OriginStr = (Origin.str().empty()) ? LogName : Origin.str();
+    *ErrorOS << OriginStr << " : ";
   } else {
-    *ErrorOS << S;
+    *ErrorOS << LogName << " : ";
   }
+
+  if (ColorDiagnostics)
+    ErrorOS->changeColor(Color);
+
+  *ErrorOS << LevelText;
+
+  if (ColorDiagnostics)
+    ErrorOS->resetColor();
+
+  *ErrorOS << ": " << Msg << "\n";
 }
 
 void ErrorHandler::log(const Twine &Msg) {
   if (Verbose) {
     std::lock_guard<std::mutex> Lock(Mu);
     *ErrorOS << LogName << ": " << Msg << "\n";
   }
 }
 
 void ErrorHandler::message(const Twine &Msg) {
   std::lock_guard<std::mutex> Lock(Mu);
   outs() << Msg << "\n";
   outs().flush();
 }
 
-void ErrorHandler::warn(const Twine &Msg) {
+void ErrorHandler::warn(const Twine &Msg, const Twine &Origin) {
   if (FatalWarnings) {
-    error(Msg);
+    error(Msg, Origin);
     return;
   }
 
   std::lock_guard<std::mutex> Lock(Mu);
-  newline(ErrorOS, Msg);
-  print("warning: ", raw_ostream::MAGENTA);
-  *ErrorOS << Msg << "\n";
+  print(Msg, Origin, "warning", raw_ostream::MAGENTA);
 }
 
-void ErrorHandler::error(const Twine &Msg) {
+void ErrorHandler::error(const Twine &Msg, const Twine &Origin) {
   std::lock_guard<std::mutex> Lock(Mu);
-  newline(ErrorOS, Msg);
 
   if (ErrorLimit == 0 || ErrorCount < ErrorLimit) {
-    print("error: ", raw_ostream::RED);
-    *ErrorOS << Msg << "\n";
+    print(Msg, Origin, "error", raw_ostream::RED);
   } else if (ErrorCount == ErrorLimit) {
-    print("error: ", raw_ostream::RED);
     *ErrorOS << ErrorLimitExceededMsg << "\n";
     if (ExitEarly)
       exitLld(1);
   }
 
   ++ErrorCount;
 }
 
-void ErrorHandler::fatal(const Twine &Msg) {
-  error(Msg);
+void ErrorHandler::fatal(const Twine &Msg, const Twine &Origin) {
+  error(Msg, Origin);
   exitLld(1);
 }

ELF/Driver.h

 
 extern class LinkerDriver *Driver;
 
 class LinkerDriver {
 public:
   void main(ArrayRef<const char *> Args);
   void addFile(StringRef Path, bool WithLOption);
   void addLibrary(StringRef Name);
+  void setDiagnosticSrcDefault(const StringRef srcDefault);
+  const StringRef diagnosticSrcDefault();
 
 private:
   void readConfigs(llvm::opt::InputArgList &Args);
   void createFiles(llvm::opt::InputArgList &Args);
   void inferMachineType();
   template <class ELFT> void link(llvm::opt::InputArgList &Args);
 
+
   // True if we are in --whole-archive and --no-whole-archive.
   bool InWholeArchive = false;
 
   // True if we are in --start-lib and --end-lib.
   bool InLib = false;
 
   // True if we are in -format=binary and -format=elf.
   bool InBinary = false;
 
   std::vector<InputFile *> Files;
+
+  // String for diagnostic Src parameter, when there is no source file.
+  // Previously stored as 'LogName' in the ErrorHandler class.
+  std::string DiagnosticSourceDefault = "lld";
 };
 
 // Parses command line options.
 class ELFOptTable : public llvm::opt::OptTable {
 public:
   ELFOptTable();
-  llvm::opt::InputArgList parse(ArrayRef<const char *> Argv);
+  llvm::opt::InputArgList parse(StringRef linkerExeName,
+                                ArrayRef<const char *> Argv);
 };
 
 // Create enum with OPT_xxx values for each option in Options.td
 enum {
   OPT_INVALID = 0,
 #define OPTION(_1, _2, ID, _4, _5, _6, _7, _8, _9, _10, _11, _12) OPT_##ID,
 #include "Options.inc"
 #undef OPTION

ELF/Driver.cpp

 
 Configuration *elf::Config;
 LinkerDriver *elf::Driver;
 
 static void setConfigs(opt::InputArgList &Args);
 
 bool elf::link(ArrayRef<const char *> Args, bool CanExitEarly,
                raw_ostream &Error) {
   errorHandler().LogName = Args[0];
   errorHandler().ErrorLimitExceededMsg =
       "too many errors emitted, stopping now (use "
       "-error-limit=0 to see all errors)";
   errorHandler().ErrorOS = &Error;
   errorHandler().ExitEarly = CanExitEarly;
   errorHandler().ColorDiagnostics = Error.has_colors();
 
   InputSections.clear();
   OutputSections.clear();

 static void checkZOptions(opt::InputArgList &Args) {
   for (auto *Arg : Args.filtered(OPT_z))
     if (!isKnown(Arg->getValue()))
       error("unknown -z value: " + StringRef(Arg->getValue()));
 }
 
 void LinkerDriver::main(ArrayRef<const char *> ArgsArr) {
   ELFOptTable Parser;
-  opt::InputArgList Args = Parser.parse(ArgsArr.slice(1));
+
+  // Extract the executable name for diagnostic print outs
+  StringRef linkerExecutableName = ArgsArr[0];
+  opt::InputArgList Args = Parser.parse(linkerExecutableName, ArgsArr.slice(1));
+
 
   // Interpret this flag early because error() depends on them.
   errorHandler().ErrorLimit = args::getInteger(Args, OPT_error_limit, 20);
 
   // Handle -help
   if (Args.hasArg(OPT_help)) {
     printHelp();
     return;

 
 // Initializes Config members by the command line options.
 void LinkerDriver::readConfigs(opt::InputArgList &Args) {
   errorHandler().Verbose = Args.hasArg(OPT_verbose);
   errorHandler().FatalWarnings =
       Args.hasFlag(OPT_fatal_warnings, OPT_no_fatal_warnings, false);
   ThreadsEnabled = Args.hasFlag(OPT_threads, OPT_no_threads, true);
 
   Config->AllowMultipleDefinition =
       Args.hasFlag(OPT_allow_multiple_definition,
                    OPT_no_allow_multiple_definition, false) ||
       hasZOption(Args, "muldefs");
   Config->AuxiliaryList = args::getStrings(Args, OPT_auxiliary);
   Config->Bsymbolic = Args.hasArg(OPT_Bsymbolic);
   Config->BsymbolicFunctions = Args.hasArg(OPT_Bsymbolic_functions);
   Config->CheckSections =
       Args.hasFlag(OPT_check_sections, OPT_no_check_sections, true);
   Config->Chroot = Args.getLastArgValue(OPT_chroot);
template <class ELFT> void LinkerDriver::link(opt::InputArgList &Args) {
   // Read the callgraph now that we know what was gced or icfed
   if (auto *Arg = Args.getLastArg(OPT_call_graph_ordering_file))
     if (Optional<MemoryBufferRef> Buffer = readFile(Arg->getValue()))
       readCallGraph(*Buffer);
 
   // Write the result to the file.
   writeResult<ELFT>();
 }
+
+void LinkerDriver::setDiagnosticSrcDefault(const StringRef srcDefault)
+{
+    DiagnosticSourceDefault = srcDefault;
+}
+
+const StringRef LinkerDriver::diagnosticSrcDefault()
+{
+    return DiagnosticSourceDefault;
+}

ELF/DriverUtils.cpp

for (size_t I = 0, E = Args.size(); I != E; ++I) {
     } else {
       V.push_back(Args[I]);
     }
   }
   Args = std::move(V);
 }
 
 // Parses a given list of options.
-opt::InputArgList ELFOptTable::parse(ArrayRef<const char *> Argv) {
+opt::InputArgList ELFOptTable::parse(StringRef linkerExeName,
+                                     ArrayRef<const char *> Argv) {
   // Make InputArgList from string vectors.
   unsigned MissingIndex;
   unsigned MissingCount;
   SmallVector<const char *, 256> Vec(Argv.data(), Argv.data() + Argv.size());
 
   // We need to get the quoting style for response files before parsing all
   // options so we parse here before and ignore all the options but
   // --rsp-quoting.
   opt::InputArgList Args = this->ParseArgs(Vec, MissingIndex, MissingCount);
 
   // Expand response files (arguments in the form of @<filename>)
   // and then parse the argument again.
   cl::ExpandResponseFiles(Saver, getQuotingStyle(Args), Vec);
   concatLTOPluginOptions(Vec);
   Args = this->ParseArgs(Vec, MissingIndex, MissingCount);
 
+  // We need to set a Visual Studio compatible default source,
+  // which is the diagnostic message prefix or 'origin', before any calls to
+  // error(), warn() or fatal().
+  if (Args.hasArg(OPT_visual_studio_diagnostics_format)) {
+    Driver->setDiagnosticSrcDefault(
+        sys::path::stem(sys::path::filename(linkerExeName)));
+    errorHandler().VSDiagnostics = true;
+  } else {
+    Driver->setDiagnosticSrcDefault(linkerExeName);
+  }
+
+  errorHandler().LogName = Driver->diagnosticSrcDefault();
   handleColorDiagnostics(Args);
+
   if (MissingCount)
     error(Twine(Args.getArgString(MissingIndex)) + ": missing argument");
 
   for (auto *Arg : Args.filtered(OPT_UNKNOWN))
     error("unknown argument: " + Arg->getSpelling());
   return Args;
 }
 

ELF/InputFiles.cpp

Optional<MemoryBufferRef> elf::readFile(StringRef Path) {
 
   if (Tar)
     Tar->append(relativeToRoot(Path), MBRef.getBuffer());
   return MBRef;
 }
 
 // Concatenates arguments to construct a string representing an error location.
 static std::string createFileLineMsg(StringRef Path, unsigned Line) {
+  // Visual Studio diagnostics format stipulates paranthesized line and
+  // column information.
+  if (errorHandler().VSDiagnostics)
+    return Path.str() + " (" + std::to_string(Line) + ")";
+
   std::string Filename = path::filename(Path);
   std::string Lineno = ":" + std::to_string(Line);
   if (Filename == Path)
     return Filename + Lineno;
   return Filename + Lineno + " (" + Path.str() + Lineno + ")";
 }
 
 template <class ELFT>
 static std::string getSrcMsgAux(ObjFile<ELFT> &File, const Symbol &Sym,
                                 InputSectionBase &Sec, uint64_t Offset) {
   // In DWARF, functions and variables are stored to different places.
   // First, lookup a function for a given offset.
   if (Optional<DILineInfo> Info = File.getDILineInfo(&Sec, Offset))
     return createFileLineMsg(Info->FileName, Info->Line);
 
   // If it failed, lookup again as a variable.
   if (Optional<std::pair<std::string, unsigned>> FileLine =

ELF/InputSection.cpp

if (auto *D = dyn_cast<Defined>(B))
         if (D->Value <= Offset && Offset < D->Value + D->Size)
           return SrcFile + ":(function " + toString(*D) + ")";
 
   // If there's no symbol, print out the offset in the section.
   return (SrcFile + ":(" + Name + "+0x" + utohexstr(Offset) + ")").str();
 }
 
 // This function is intended to be used for constructing an error message.
-// The returned message looks like this:
+// By default, the returned message looks like this:
 //
 //   foo.c:42 (/home/alice/possibly/very/long/path/foo.c:42)
 //
+// If Visual Studio diagnostics compatibility is enabled the format
+// is different:
+//
+// /home/alice/possibly/very/long/path/foo.c (42)
+//
 //  Returns an empty string if there's no way to get line info.
 std::string InputSectionBase::getSrcMsg(const Symbol &Sym, uint64_t Offset) {
   // Synthetic sections don't have input files.
   if (!File)
     return "";
   return File->getSrcMsg(Sym, *this, Offset);
 }
 
for (const RelTy &Rel : Rels) {
     if (Expr == R_NONE)
       continue;
 
     if (Expr != R_ABS) {
       std::string Msg = getLocation<ELFT>(Offset) +
                         ": has non-ABS relocation " + toString(Type) +
                         " against symbol '" + toString(Sym) + "'";
       if (Expr != R_PC) {
-        error(Msg);
+        error(Msg, errorHandler().LogName);
         return;
       }
 
       // If the control reaches here, we found a PC-relative relocation in a
       // non-ALLOC section. Since non-ALLOC section is not loaded into memory
       // at runtime, the notion of PC-relative doesn't make sense here. So,
       // this is a usage error. However, GNU linkers historically accept such
       // relocations without any errors and relocate them as if they were at
       // address 0. For bug-compatibilty, we accept them with warnings. We
       // know Steel Bank Common Lisp as of 2018 have this bug.
-      warn(Msg);
+      warn(Msg, errorHandler().LogName);
       Target->relocateOne(BufLoc, Type,
                           SignExtend64<Bits>(Sym.getVA(Addend - Offset)));
       continue;
     }
 
     if (Sym.isTls() && !Out::TlsPhdr)
       Target->relocateOne(BufLoc, Type, 0);
     else

ELF/Options.td

defm whole_archive: B<"whole-archive",
     "Do not force load of all members in a static library (default)">;
 
 defm wrap: Eq<"wrap", "Use wrapper functions for symbol">,
   MetaVarName<"<symbol>=<symbol>">;
 
 def z: JoinedOrSeparate<["-"], "z">, MetaVarName<"<option>">,
   HelpText<"Linker option extensions">;
 
+def visual_studio_diagnostics_format : F<"vs-diagnostics">,
+  HelpText<"Format diagnostics for Visual Studio compatiblity">;
+
 // Aliases
 def: Separate<["-"], "f">, Alias<auxiliary>, HelpText<"Alias for --auxiliary">;
 def: F<"call_shared">, Alias<Bdynamic>, HelpText<"Alias for --Bdynamic">;
 def: F<"dy">, Alias<Bdynamic>, HelpText<"Alias for --Bdynamic">;
 def: F<"dn">, Alias<Bstatic>, HelpText<"Alias for --Bstatic">;
 def: F<"non_shared">, Alias<Bstatic>, HelpText<"Alias for --Bstatic">;
 def: F<"static">, Alias<Bstatic>, HelpText<"Alias for --Bstatic">;
 def: Flag<["-"], "d">, Alias<define_common>, HelpText<"Alias for --define-common">;

ELF/Relocations.cpp

static bool maybeReportUndefined(Symbol &Sym, InputSectionBase &Sec,
 
   std::string Src = Sec.getSrcMsg(Sym, Offset);
   if (!Src.empty())
     Msg += Src + "\n>>>               ";
   Msg += Sec.getObjMsg(Offset);
 
   if ((Config->UnresolvedSymbols == UnresolvedPolicy::Warn && CanBeExternal) ||
       Config->NoinhibitExec) {
-    warn(Msg);
+    warn(Msg, Src);
     return false;
   }
 
-  error(Msg);
+  error(Msg, Src);
   return true;
 }
 
 // MIPS N32 ABI treats series of successive relocations with the same offset
 // as a single relocation. The similar approach used by N64 ABI, but this ABI
 // packs all relocations into the single relocation record. Here we emulate
 // this for the N32 ABI. Iterate over relocation with the same offset and put
 // theirs types into the single bit-set.

ELF/SymbolTable.cpp

if (Size > Bss->Size) {
     D->Size = Bss->Size = Size;
   }
   return S;
 }
 
 static void reportDuplicate(Symbol *Sym, InputFile *NewFile) {
   if (!Config->AllowMultipleDefinition)
     error("duplicate symbol: " + toString(*Sym) + "\n>>> defined in " +
-          toString(Sym->File) + "\n>>> defined in " + toString(NewFile));
+              toString(Sym->File) + "\n>>> defined in " + toString(NewFile),
+          toString(NewFile));
 }
 
 static void reportDuplicate(Symbol *Sym, InputFile *NewFile,
                             InputSectionBase *ErrSec, uint64_t ErrOffset) {
   if (Config->AllowMultipleDefinition)
     return;
 
   Defined *D = cast<Defined>(Sym);
   if (!D->Section || !ErrSec) {
     reportDuplicate(Sym, NewFile);
     return;
   }
 
-  // Construct and print an error message in the form of:
+  // Construct and print an error message.
+  //
+  // In default diagnostics mode the format is:
   //
   //   ld.lld: error: duplicate symbol: foo
   //   >>> defined at bar.c:30
   //   >>>            bar.o (/home/alice/src/bar.o)
   //   >>> defined at baz.c:563
   //   >>>            baz.o in archive libbaz.a
+  //
+  // In Visual Studio compatible diagnostics mode the format is:
+  //
+  //   bar.c (30): error: duplicate symbol: foo
+  //   >>> defined at bar.c:30
+  //   >>>            bar.o (/home/alice/src/bar.o)
+  //   >>> defined at baz.c:563
+  //   >>>            baz.o in archive libbaz.a
+
   auto *Sec1 = cast<InputSectionBase>(D->Section);
   std::string Src1 = Sec1->getSrcMsg(*Sym, D->Value);
   std::string Obj1 = Sec1->getObjMsg(D->Value);
   std::string Src2 = ErrSec->getSrcMsg(*Sym, ErrOffset);
   std::string Obj2 = ErrSec->getObjMsg(ErrOffset);
 
   std::string Msg = "duplicate symbol: " + toString(*Sym) + "\n>>> defined at ";
   if (!Src1.empty())
     Msg += Src1 + "\n>>>            ";
   Msg += Obj1 + "\n>>> defined at ";
   if (!Src2.empty())
     Msg += Src2 + "\n>>>            ";
   Msg += Obj2;
-  error(Msg);
+  error(Msg, Sec1->getSrcMsg(*Sym, D->Value));
 }
 
 Symbol *SymbolTable::addRegular(StringRef Name, uint8_t StOther, uint8_t Type,
                                 uint64_t Value, uint64_t Size, uint8_t Binding,
                                 SectionBase *Section, InputFile *File) {
   Symbol *S;
   bool WasInserted;
   std::tie(S, WasInserted) = insert(Name, Type, getVisibility(StOther),

include/lld/Common/ErrorHandler.h

public:
   uint64_t ErrorLimit = 20;
   StringRef ErrorLimitExceededMsg = "too many errors emitted, stopping now";
   StringRef LogName = "lld";
   llvm::raw_ostream *ErrorOS = &llvm::errs();
   bool ColorDiagnostics = llvm::errs().has_colors();
   bool ExitEarly = true;
   bool FatalWarnings = false;
   bool Verbose = false;
+  bool VSDiagnostics = false;
 
-  void error(const Twine &Msg);
-  LLVM_ATTRIBUTE_NORETURN void fatal(const Twine &Msg);
+  void error(const Twine &Msg, const Twine &Origin);
+  LLVM_ATTRIBUTE_NORETURN void fatal(const Twine &Msg, const Twine &Origin);
   void log(const Twine &Msg);
   void message(const Twine &Msg);
-  void warn(const Twine &Msg);
+  void warn(const Twine &Msg, const Twine &Origin);
 
   std::unique_ptr<llvm::FileOutputBuffer> OutputBuffer;
 
 private:
-  void print(StringRef S, raw_ostream::Colors C);
+    void print(const Twine &Msg, const Twine &Origin, const Twine &LevelText,
+        const raw_ostream::Colors Color);
 };
 
 /// Returns the default error handler.
 ErrorHandler &errorHandler();
 
-inline void error(const Twine &Msg) { errorHandler().error(Msg); }
-inline LLVM_ATTRIBUTE_NORETURN void fatal(const Twine &Msg) {
-  errorHandler().fatal(Msg);
+inline void error(const Twine &Msg, const Twine &Origin = "") {
+  errorHandler().error(Msg, Origin);
+}
+inline LLVM_ATTRIBUTE_NORETURN void fatal(const Twine &Msg,
+                                          const Twine &Origin = "") {
+  errorHandler().fatal(Msg, Origin);
 }
 inline void log(const Twine &Msg) { errorHandler().log(Msg); }
 inline void message(const Twine &Msg) { errorHandler().message(Msg); }
-inline void warn(const Twine &Msg) { errorHandler().warn(Msg); }
+inline void warn(const Twine &Msg, const Twine &Origin = "") {
+  errorHandler().warn(Msg, Origin);
+}
 inline uint64_t errorCount() { return errorHandler().ErrorCount; }
 
 LLVM_ATTRIBUTE_NORETURN void exitLld(int Val);
 
 void diagnosticHandler(const llvm::DiagnosticInfo &DI);
 void checkError(Error E);
 
 // check functions are convenient functions to strip errors

test/ELF/Inputs/vs-diagnostics-bad-relocation.test

+!ELF
+FileHeader:
+  Class:           ELFCLASS32
+  Data:            ELFDATA2LSB
+  Type:            ET_REL
+  Machine:         EM_386
+Sections:
+  - Type:            SHT_PROGBITS
+    Name:            .text
+    Flags:           [ ]
+    AddressAlign:    0x04
+    Content:         "0000"
+  - Type:            SHT_PROGBITS
+    Name:            .debug_info
+    Flags:           [ ]
+    AddressAlign:    0x04
+    Content:         "0000"
+  - Type:            SHT_REL
+    Name:            .rel.debug_info
+    Link:            .symtab
+    Info:            .debug_info
+    Relocations:
+      - Offset:          0
+        Symbol:          _start
+        Type:            0xFF
+      - Offset:          4
+        Symbol:          _start
+        Type:            0xFF
+Symbols:
+  Global:
+    - Name:     _start
+      Type:     STT_FUNC
+      Section:  .text
+      Value:    0x0

test/ELF/Inputs/vs-diagnostics-multiply-defined.s

+.file "vs-diagnostics-multiply-defined.s"
+.globl wump
+wump:

test/ELF/Inputs/vs-diagnostics-non-abs-reloc.test

+!ELF
+FileHeader:
+  Class:           ELFCLASS64
+  Data:            ELFDATA2LSB
+  Type:            ET_REL
+  Machine:         EM_X86_64
+Sections:
+  - Type:            SHT_PROGBITS
+    Name:            .text
+    Flags:           [ ]
+    AddressAlign:    0x04
+    Content:         "0000"
+  - Type:            SHT_PROGBITS
+    Name:            .debug_info
+    Flags:           [ ]
+    AddressAlign:    0x04
+    Content:         "0000"
+  - Type:            SHT_REL
+    Name:            .rel.debug_info
+    Link:            .symtab
+    Info:            .debug_info
+    Relocations:
+      - Offset:          0
+        Symbol:          _start
+        Type:            0x02
+      - Offset:          4
+        Symbol:          _start
+        Type:            0x02
+Symbols:
+  Global:
+    - Name:     _start
+      Type:     STT_FUNC
+      Section:  .text
+      Value:    0x0

test/ELF/vs-diagnostics.s

+## We repeat all tests with and without the vs-diagnostics flag enabled
+## to demonstrate the output differences.
+# REQUIRES: x86
+# RUN: rm -rf %t.dir && mkdir -p %t.dir
+
+## Check error message output when source information is provided.
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t.dir/vs-diagnostics.o
+## Without --vs-diagnostics:
+# RUN: not ld.lld %t.dir/vs-diagnostics.o 2>&1 | \
+# RUN:   FileCheck --strict-whitespace -check-prefix=SOURCE -D=PATH=%t.dir %s
+
+# SOURCE: {{.+}}ld.lld{{(.EXE|.exe)?}} : error: undefined symbol: flump
+# SOURCE-NEXT: >>> referenced by vs-diagnostics.s:1215
+# SOURCE-NEXT: >>>               [[PATH]]{{\\|\/}}vs-diagnostics.o:(.text+0x1){{$}}
+# SOURCE-SAME: {{[[:space:]]$}}
+# SOURCE-NEXT: {{.+}}ld.lld{{(.EXE|.exe)?}} : error: undefined symbol: foo
+# SOURCE-NEXT: >>> referenced by vs-diagnostics.s:1066
+# SOURCE-NEXT: >>>               [[PATH]]{{\\|\/}}vs-diagnostics.o:(.text+0x6)
+
+## With --vs-diagnostics:
+# RUN: not ld.lld --vs-diagnostics %t.dir/vs-diagnostics.o 2>&1 | \
+# RUN:   FileCheck --strict-whitespace -check-prefix=VSSOURCE -D=PATH=%t.dir %s
+
+# VSSOURCE: vs-diagnostics.s (1215) : error: undefined symbol: flump
+# VSSOURCE-NEXT: >>> referenced by vs-diagnostics.s
+# VSSOURCE-NEXT: >>>               [[PATH]]{{\\|\/}}vs-diagnostics.o:(.text+0x1){{$}}
+# VSSOURCE-SAME: {{[[:space:]]$}}
+# VSSOURCE-NEXT: vs-diagnostics.s (1066) : error: undefined symbol: foo
+# VSSOURCE-NEXT: >>> referenced by vs-diagnostics.s
+# VSSOURCE-NEXT: >>>               [[PATH]]{{\\|\/}}vs-diagnostics.o:(.text+0x6)
+
+## Check error message output for duplicate symbols
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %p/Inputs/vs-diagnostics-multiply-defined.s \
+# RUN:   -o %t.dir/vs-diagnostics-multiply-defined.o
+## Without --vs-diagnostics:
+# RUN: not ld.lld %t.dir/vs-diagnostics-multiply-defined.o  %t.dir/vs-diagnostics-multiply-defined.o 2>&1 | \
+# RUN:   FileCheck --strict-whitespace -check-prefix=NOSOURCE -D=PATH=%t.dir %s
+
+# NOSOURCE: {{.+}}ld.lld{{(.EXE|.exe)?}} : error: duplicate symbol: wump
+# NOSOURCE-NEXT: >>> defined at vs-diagnostics-multiply-defined.s
+# NOSOURCE-NEXT: >>>            [[PATH]]{{\\|\/}}vs-diagnostics-multiply-defined.o:(.text+0x0)
+# NOSOURCE-NEXT: >>> defined at vs-diagnostics-multiply-defined.s
+# NOSOURCE-NEXT: >>>            [[PATH]]{{\\|\/}}vs-diagnostics-multiply-defined.o:(.text+0x0)
+
+## With --vs-diagnostics:
+# RUN: not ld.lld --vs-diagnostics %t.dir/vs-diagnostics-multiply-defined.o %t.dir/vs-diagnostics-multiply-defined.o 2>&1 | \
+# RUN:   FileCheck --strict-whitespace -check-prefix=VSNOSOURCE -D=PATH=%t.dir %s
+
+# VSNOSOURCE: vs-diagnostics-multiply-defined.s : error: duplicate symbol: wump
+# VSNOSOURCE-NEXT: >>> defined at vs-diagnostics-multiply-defined.s
+# VSNOSOURCE-NEXT: >>>            [[PATH]]{{\\|\/}}vs-diagnostics-multiply-defined.o:(.text+0x0)
+# VSNOSOURCE-NEXT: >>> defined at vs-diagnostics-multiply-defined.s
+# VSNOSOURCE-NEXT: >>>            [[PATH]]{{\\|\/}}vs-diagnostics-multiply-defined.o:(.text+0x0)
+
+## Check warning message output for a non-ABS relocation R_X86_64_PC32 against symbol '_start'
+# RUN: yaml2obj %p/Inputs/vs-diagnostics-non-abs-reloc.test -o %t.dir/vs-diagnostics-non-abs-reloc.o
+
+## without --vs-diagnostics 
+# RUN: ld.lld %t.dir/vs-diagnostics-non-abs-reloc.o 2>&1 | FileCheck -check-prefix=NONABS -D=PATH=%t.dir %s
+# NONABS: {{.+}}ld.lld{{(.EXE|.exe)?}} : warning: [[PATH]]/vs-diagnostics-non-abs-reloc.o:(.debug_info+0x0): has non-ABS relocation R_X86_64_PC32 against symbol '_start'
+# NONABS-NEXT: (.debug_info+0x4): has non-ABS relocation R_X86_64_PC32 against symbol '_start'
+
+## with --vs-diagnostics
+# RUN: ld.lld --vs-diagnostics %t.dir/vs-diagnostics-non-abs-reloc.o 2>&1 | FileCheck -check-prefix=VSNONABS -D=PATH=%t.dir %s
+# VSNONABS: ld.lld : warning: [[PATH]]/vs-diagnostics-non-abs-reloc.o:(.debug_info+0x0): has non-ABS relocation R_X86_64_PC32 against symbol '_start'
+# VSNONABS-NEXT: (.debug_info+0x4): has non-ABS relocation R_X86_64_PC32 against symbol '_start'
+
+## Check error message output for a bad relocation type (value 0xff)
+# RUN: yaml2obj %p/Inputs/vs-diagnostics-bad-relocation.test -o %t.dir/vs-diagnostics-bad-relocation.o
+
+## without --vs-diagnostics
+# RUN: not ld.lld -gdb-index %t.dir/vs-diagnostics-bad-relocation.o -o %t.dir/vs-diagnostics-bad-relocation.exe 2>&1 | FileCheck -check-prefix=BADRELOC %s
+# BADRELOC: {{.+}}ld.lld{{(.EXE|.exe)?}} : error: {{.*}}vs-diagnostics-bad-relocation.o:(.debug_info+0x0): has non-ABS relocation Unknown (255) against symbol '_start'
+
+## with vs-diagnostics
+# RUN: not ld.lld --vs-diagnostics -gdb-index %t.dir/vs-diagnostics-bad-relocation.o -o %t.dir/vs-diagnostics-bad-relocation.exe 2>&1 | FileCheck -check-prefix=VSBADRELOC -D=PATH=%t.dir %s
+# VSBADRELOC: ld.lld : error: {{.*}}vs-diagnostics-bad-relocation.o:(.debug_info+0x0): has non-ABS relocation Unknown (255) against symbol '_start'
+
+## Check that we have configured the diagnostic prefix early enough
+## so that the output is VS conformant when reporting an unknown command line
+## argument.
+
+## Without --vs-diagnostics:
+# RUN: not ld.lld --nonexistantflag %t.o 2>&1 | \
+# RUN:   FileCheck -check-prefix=EARLY %s
+
+# EARLY: {{.+}}ld.lld{{(.EXE|.exe)?}} : error: unknown argument: --nonexistantflag
+
+## With -- vs-diagnostics:
+# RUN: not ld.lld --nonexistantflag --vs-diagnostics %t.o 2>&1 | \
+# RUN:   FileCheck -check-prefix=VSEARLY %s
+
+# VSEARLY: ld.lld : error: unknown argument: --nonexistantflag
+
+.file 1 "vs-diagnostics.s"
+.text
+  .globl _start
+_start:
+  .loc 1 1215
+  call flump
+  .loc 1 1066
+  call foo
+end_start:
+
+.section  .debug_abbrev,"",@progbits
+.byte  1  # Abbreviation Code
+.byte  17 # DW_TAG_compile_unit
+.byte  0  # DW_CHILDREN_no
+.byte 16  # DW_AT_stmt_list
+.byte 23  # DW_FORM_sec_offset
+.byte 17  # DW_AT_low_pc
+.byte 1   # DW_FORM_addr
+.byte 18  # DW_AT_high_pc
+.byte 6   # DW_FORM_data4
+.byte 0   # EOM(1)
+.byte 0   # EOM(2)
+.byte 0   # EOM(3)
+
+.section .debug_info,"",@progbits
+.long  .end_debug_info - .start_debug_info # Length of Unit
+.start_debug_info:
+.short  4                      # DWARF version number
+.long  .debug_abbrev           # Offset Into Abbrev. Section
+.byte  8                       # Address Size (in bytes)
+.byte  1                       # Abbrev [1] 0xb:0x19 DW_TAG_compile_unit
+.long .Lline_table_start0      # DW_AT_stmt_list
+.quad _start
+.long end_start - _start
+.end_debug_info:
+
+.section  .debug_line,"",@progbits
+
+.Lline_table_start0: