[cfe-dev] Need help designing a new diagnostic formatting command line option for use with x86_64-pc-win32

Ted Kremenek kremenek at apple.com
Wed May 18 11:24:01 PDT 2011


Hi Andrew, Doug,

I'm wondering if support for Microsoft-style diagnostics should be implemented as a new DiagnosticClient (e.g., MSVCTextDiagnosticPrinter).  I'm not certain what the plan was, but putting this all into TextDiagnosticPrinter seems a little gross to me.  With a separate DiagnosticClient, we might not need extra bits in DiagnosticOptions.

Just my $0.02.

Ted

On May 18, 2011, at 8:52 AM, Douglas Gregor wrote:

> Hi Andrew,
> 
> On May 18, 2011, at 12:03 AM, Andrew Fish wrote:
> 
>> For EFI firmware we use x86_64-pc-win32-darwin, but the default behavior for diagnostics on this triple is to suppress column number printing, and format line numbers to be compatible with Visual Studio. This breaks our Xcode IDE, and command line yank put. Attached is my first take at a patch to fix this. IMHO the default diagnostic output for clang, should be clangs native diagnostic output that matches the documentation. I understand the need to modify the output to match the IDE that is being used, as I'm fixing that reverse problem. It would seem OK to add a flag, like -fno-diagnostic-standard-format, when clang is being used with an incompatible IDE.  
>> 
>> 
>> -f[no-]diagnostics-standard-format: Print diagnostics in standard clang format, or a non standard OS specific format.
>> This option, which defaults to on, controls whether or not Clang uses the default diagnostic output format, or use an OS specific diagnostic format. For example, when this is disabled for the x86_64-pc-win32 triple, Clang will modify diagnostic output something like:
>>   test.c(2): error: unknown type name 'asdkjf' 
>>   asdkjf
>>   ^
>> Note: This changes the default behavior today so it would look like this (normal clang):
>> 
>> clang -ccc-host-triple x86_64-pc-win32  ve.c  -S 
>> ve.c:2:1: error: unknown type name 'asdkjf'
>> asdkjf  
>> ^
>> 
>> To get the old behavior you need to add the new flag:
>> 
>> clang -ccc-host-triple x86_64-pc-win32  ve.c  -S -fno-diagnostics-standard-format
>> ve.c(2) :  error: unknown type name 'asdkjf'
>> asdkjf  
>> ^
>> 
>> 
>> If I was doing this from scratch I would probably add a flag per IDE that was not compatible with the clang diagnostics format that would modify the clang diagnostic output to be compatible for that IDE. So something like  -fdiagnostics-ide=VisualStudio or -fdiagnostics-vi.
> 
> I think this is the superior design, with something like -fdiagnostics-format=msvc used to indicate how we should format diagnostics. It'll scale if we end up having to support some other display format for a different IDE or compiler.
> 
>> I picked --fno-diagnostic-standard-format to better match what the currently code was doing:
>> 
>>  if (LangOpts && LangOpts->Microsoft) {
> 
> The current code is really sketchy, since it conflates a language-parsing option with a diagnostic-display option, when these should be disjoint subsystems. 
> 
>> Given I'm a novice at clang, llvm, and C++ I figured changing as little as possible was a good plan. 
> 
> That's understandable, and your patch looks quite good. The only change I would have requested would be to add "-fdiagnostic-standard-format" as well as "-fno-diagnostic-standard-format", because then the driver can be taught how to take the last flag from the command line, e.g.,
> 
> 	clang -fno-diagnostic-standard-format t.c -fdiagnostic-standard-format
> 
> However, I think the best way forward is to implement -fdiagnostics-format=xxx, where "xxx" is either clang (the default) or msvc (Visual Studio-style). If the -fdiagnostics-format=xxx option isn't provided to the driver, the driver will pick based on the target triple, so that non-EFI MSVC targets get "msvc" and other targets get "clang". 
> 
> 	- Doug
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110518/096673d1/attachment.html>


More information about the cfe-dev mailing list