On 10/12/2013 18:03, Jim Grosbach wrote:>> That causes dissonance between what the compiler sees and what lit.py >> sees for no particularly good reason. One of the nice properties of >> lit tests is that they're also valid compiler inputs, so trailing >> slash is a bit unfortunate. >> > > How does the backslash break this in any way?The backslash is interpreted by lit and the compiler in different and incompatible ways. Spot the problem in this reduced example.. // expected-no-diagnostics // RUN: %clang_cc1 %s -verify -emit-llvm -o - | \ __attribute__((packed)) // no warning int x; // RUN: FileCheck %s // CHECK: @x = common global i32 0, align 4 It is easier to get this wrong than it is to get it right -- in effect, lit is encouraging use of backslash line continuations which are guaranteed to change the meaning of the following line in C/C++ with a silent failure mode. This is concerning for a C/C++ compiler test suite :-) It's problematic because the feature hides test issues in and of itself by being incompatible with C, but moreover because it breaks stock tools used to check code and comments due to the complex sub-grammar introduced. It's really important to me that there's buy-in for this though -- the last thing I want is for people to say "Alp made my tests hard to read" after the fact(!) Cheers, Alp. -- http://www.nuanti.com the browser experts -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131210/ea9b504c/attachment.html>
On Dec 10, 2013, at 11:26 AM, Alp Toker <alp at nuanti.com> wrote:> > On 10/12/2013 18:03, Jim Grosbach wrote: >>> That causes dissonance between what the compiler sees and what lit.py sees for no particularly good reason. One of the nice properties of lit tests is that they're also valid compiler inputs, so trailing slash is a bit unfortunate. >>> >> >> How does the backslash break this in any way? > > The backslash is interpreted by lit and the compiler in different and incompatible ways.I disagree that this is different or incompatible. In any case, you didn’t answer the more important of my two questions. What compilers interpret this code differently?> > Spot the problem in this reduced example.. > > // expected-no-diagnostics > > // RUN: %clang_cc1 %s -verify -emit-llvm -o - | \ > __attribute__ ((packed)) // no warning > int x; > // RUN: FileCheck %s > // CHECK: @x = common global i32 0, align 4 >The attribute line is a comment, which any reasonable syntax highlighting editor will show you if you’re not used to looking for these sorts of things. lit should generate a diagnostic (probably an error) for this code, however. It’s malformed.> It is easier to get this wrong than it is to get it right -- in effect, lit is encouraging use of backslash line continuations which are guaranteed to change the meaning of the following line in C/C++ with a silent failure mode. This is concerning for a C/C++ compiler test suite :-) > > It's problematic because the feature hides test issues in and of itself by being incompatible with C, but moreover because it breaks stock tools used to check code and comments due to the complex sub-grammar introduced. > > It's really important to me that there's buy-in for this though -- the last thing I want is for people to say "Alp made my tests hard to read" after the fact(!)If you necessitate test run lines longer than 80 characters, you will be making tests much harder for me to read. This isn’t a problem with the lit RUN line syntax. It’s a problem with lit being far too permissive and not screaming when it sees obviously malformed code.> > Cheers, > Alp. > > > -- > http://www.nuanti.com > the browser experts-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131210/a816120c/attachment.html>
On 10/12/2013 19:47, Jim Grosbach wrote:> > On Dec 10, 2013, at 11:26 AM, Alp Toker <alp at nuanti.com > <mailto:alp at nuanti.com>> wrote: > >> >> On 10/12/2013 18:03, Jim Grosbach wrote: >>>> That causes dissonance between what the compiler sees and what >>>> lit.py sees for no particularly good reason. One of the nice >>>> properties of lit tests is that they're also valid compiler inputs, >>>> so trailing slash is a bit unfortunate. >>>> >>> >>> How does the backslash break this in any way? >> >> The backslash is interpreted by lit and the compiler in different and >> incompatible ways. > > I disagree that this is different or incompatible. > > In any case, you didn’t answer the more important of my two questions. > What compilers interpret this code differently?Hi Jim, There are lots of ways line continuations are interpreted differently between compilers and even different versions from the same vendor. This is inherent because each frontend has a different take on fundamental issues like where lines and comments begin and end, and even the semantics of what translation phases are vary between compilers. Here's one quick example of how compilers interpret this code differently: |*$* printf '//\\ \nint x=0;\nint x=0;' > f.c||| |||| |||*$* cat f.c||| |||//\ ||| |||int x=0;||| |||int x=0;||| |||| |||*$* clang -fsyntax-only f.c||| |||| |||*$* gcc-4.9 -fsyntax-only f.c||| |||| |||*$* cl f.c||| |||Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x64||| |||Copyright (C) Microsoft Corporation. All rights reserved.||| |||| ||*|f.c(3) : |**|error C2374|**|: 'x' : redefinition; multiple initialization|**||** **||**| f.c(2) : see declaration of 'x'|* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131210/307378f3/attachment.html>