[llvm-dev] RFC: LLVM - lld - Add visual studio compatible diagnostics output to lld

Rui Ueyama via llvm-dev
2018-02-22T23:37:40Z

Hi,

I understand that making lld's error message compatible with MSVC makes it
easy to use in IDEs. But at the same time I personally prefer the current
style of lld's error message because it's easier to read particularly
when
filenames or symbol names are long (which is a norm in modern projects).

I'd start with experimenting your idea with a small change. I guess that
the error message you want to format in the MSVC style is almost always
"missing symbol" error. You could change only that message locally so
that
lld prints it out in the MSVC style. If that works for you, then I guess
you can demonstrate that to convince broader audiences, and we can discuss
how we will adopt that change. What do you think?

On Mon, Feb 19, 2018 at 7:21 AM, Chris Jackson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> RFC: lld- Add visual studio compatible diagnostics output to lld
>
> Hello all,
>
> We have a proposal to extend the diagnostics output capabilities of lld.
>
> ## Problem
>
> MS Visual Studio expects the diagnostic output of build tools to conform
> to a specific format, described here: [1] and [2] . Currently lld cannot
> emit warnings and errors in this format. lld prefixes diagnostic output
> with args[0], which can be a full path to the lld executable. If a
> diagnostic message of this format is clicked within visual studio, the
> program
> attempts to open the linker executable for edit, as this is interpreted as
> a source code file. Normally this causes visual studio
> to become  unresponsive until the file open operation times out. This
> output in its current format is displayed in visual studio as:
>
> ------ Build started: Project: lldDiagnostics, Configuration: Debug ------
> X:\bin\lld.exe : error : undefined symbol: foo
> >>> referenced by diagMain.cpp:5 (X:\lldDiagnostics\
> lldDiagnostics\diagMain.cpp:5)
> >>>               Debug\diagMain.o:(main)
> Done building project "lldDiagnostics.vcxproj" -- FAILED.
> ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped
=========>
>
> ## Proposed Solution
>
> We propose the addition of an option to output diagnostics that fully
> conform to [1]. There is currently an option in clang that enables VS
> compatible output, '-fdiagnostics-format=msvc' [3] [4]. This will
enable
> visual studio to parse the full diagnostic. This will
> result in clickable links so that the IDE can display the source from
> which the error or warning originates, as well as adding errors and
> warnings to the error list.
>
> A visual studio conformant diagnostics output would look something like:
>
> X:\lldDiagnostics\lldDiagnostics\diagMain.cpp(5) : error : undefined
> symbol ‘foo’ referenced in function ‘main’ in file ‘Debug\diagMain.o’
>
> VS would be display this as:
>
> ------ Build started: Project: Project1, Configuration: Debug Win32 ------
> Link : error : L0039: reference to undefined symbol `foo' in file
> "X:\lldDiagnostics\lldDiagnostics\diagMain\diagMain.o"
> X:\lldDiagnostics\lldDiagnostics\diagMain.cpp : error : L0039: reference
> to undefined symbol `foo' in file
> "X:\lldDiagnostics\lldDiagnostics\diagMain\diagMainSource.o"
> ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped
=========>
> Thanks.
>
>
> Best Regards,
>
>
> Chris
>
>
> [1] https://docs.microsoft.com/en-us/cpp/ide/formatting-the-
> output-of-a-custom-build-step-or-build-event
> [2] https://blogs.msdn.microsoft.com/msbuild/2006/11/02/
> msbuild-visual-studio-aware-error-messages-and-message-formats/
> [3] https://clang.llvm.org/docs/UsersManual.html#cmdoption-
> fdiagnostics-format
> [4] http://lists.llvm.org/pipermail/cfe-dev/2011-May/015115.html
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180222/997908b5/attachment.html>