Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] lit: deprecating trailing \ in RUN lines"
2013 Dec 08
0
[LLVMdev] lit: deprecating trailing \ in RUN lines
On Sun, Dec 8, 2013 at 2:11 AM, Alp Toker <alp at nuanti.com> wrote:
> I'd like to propose deprecating and shortly thereafter removing the lit
> test runner feature that concatenates RUN lines ending in a trailing \
>
I'm really opposed to this. Especially for the Clang test suite where run
lines are often *very* long and hard to organize, read, and edit without
this
2013 Dec 08
5
[LLVMdev] lit: deprecating trailing \ in RUN lines
On 08/12/2013 11:22, Chandler Carruth wrote:
> On Sun, Dec 8, 2013 at 2:11 AM, Alp Toker <alp at nuanti.com
> <mailto:alp at nuanti.com>> wrote:
>
> I'd like to propose deprecating and shortly thereafter removing
> the lit test runner feature that concatenates RUN lines ending in
> a trailing \
>
>
> I'm really opposed to this. Especially
2013 Dec 08
0
[LLVMdev] lit: deprecating trailing \ in RUN lines
On Sun, Dec 8, 2013 at 4:24 AM, Alp Toker <alp at nuanti.com> wrote:
>
> On 08/12/2013 11:22, Chandler Carruth wrote:
>
> On Sun, Dec 8, 2013 at 2:11 AM, Alp Toker <alp at nuanti.com> wrote:
>
>> I'd like to propose deprecating and shortly thereafter removing the lit
>> test runner feature that concatenates RUN lines ending in a trailing \
>>
2013 Dec 10
0
[LLVMdev] lit: deprecating trailing \ in RUN lines
On Dec 8, 2013, at 4:24 AM, Alp Toker <alp at nuanti.com> wrote:
>
> On 08/12/2013 11:22, Chandler Carruth wrote:
>> On Sun, Dec 8, 2013 at 2:11 AM, Alp Toker <alp at nuanti.com> wrote:
>> I'd like to propose deprecating and shortly thereafter removing the lit test runner feature that concatenates RUN lines ending in a trailing \
>>
>> I'm
2013 Dec 08
4
[LLVMdev] lit: deprecating trailing \ in RUN lines
On 08/12/2013 13:12, Chandler Carruth wrote:
>
>> * Removing trailing \ will introduce the neat property that
>> one RUN line corresponds precisely to one command that's
>> executed. This is good for humans and will enable
>> simplifications in the test runner.
>>
>> FWIW, I've never really had a
2013 Dec 10
4
[LLVMdev] lit: deprecating trailing \ in RUN lines
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
2013 Dec 10
2
[LLVMdev] lit: deprecating trailing \ in RUN lines
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
2013 Dec 10
0
[LLVMdev] lit: deprecating trailing \ in RUN lines
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Alp Toker
> Subject: Re: [LLVMdev] lit: deprecating trailing \ in RUN lines
> //\
> int x=0;
> int x=0;
> $ gcc-4.9 -fsyntax-only f.c
Try gcc with -Wall, and you'll see the appropriate warning. Also try the MS compiler after removing the trailing space after the backslash; I
2013 Dec 10
0
[LLVMdev] lit: deprecating trailing \ in RUN lines
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.
>>>
>>
2013 Dec 10
2
[LLVMdev] lit: deprecating trailing \ in RUN lines
On Dec 10, 2013, at 1:43 PM, Caldarale, Charles R <Chuck.Caldarale at unisys.com> wrote:
>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
>> On Behalf Of Alp Toker
>> Subject: Re: [LLVMdev] lit: deprecating trailing \ in RUN lines
>
>> //\
>> int x=0;
>> int x=0;
>
>> $ gcc-4.9 -fsyntax-only f.c
>
> Try
2013 Dec 08
2
[LLVMdev] lit: deprecating trailing \ in RUN lines
On 08/12/2013 16:43, Daniel Dunbar wrote:
>
> With one-to-one mapping, it becomes possible to use simple tools
> like grep to validate common mistakes like %clang / %clang_cc1
> mixups, a missing -o flag and so on.
>
> Right now there's no obvious way to do those checks and we've
> ended up without an easy way to lint for broken tests as a result.
2013 Dec 08
0
[LLVMdev] lit: deprecating trailing \ in RUN lines
On Sun, Dec 8, 2013 at 6:04 AM, Alp Toker <alp at nuanti.com> wrote:
>
> On 08/12/2013 13:12, Chandler Carruth wrote:
>
>>
>> * Removing trailing \ will introduce the neat property that
>>>
>>> one RUN line corresponds precisely to one command that's
>>> executed. This is good for humans and will enable
2013 Dec 09
0
[LLVMdev] lit: deprecating trailing \ in RUN lines
Ok, that makes sense. I don't see this as a good enough argument to remove
backslash support though.
For problems like the clang_cc1 substitution mistakes, it would be much
better to just improve the substitution support so that those cause
immediate test failures. I would definitely support a move to make lit's
substitution machinery more strict. For problems like your first search, I
2013 Dec 10
0
[LLVMdev] lit: deprecating trailing \ in RUN lines
On Sun, Dec 8, 2013 at 9:04 AM, Alp Toker <alp at nuanti.com> wrote:
>
> On 08/12/2013 13:12, Chandler Carruth wrote:
>
>>
>> * Removing trailing \ will introduce the neat property that
>>>
>>> one RUN line corresponds precisely to one command that's
>>> executed. This is good for humans and will enable
2013 Dec 10
1
[LLVMdev] lit: deprecating trailing \ in RUN lines
On 10/12/2013 04:20, Sean Silva wrote:
> The classic way to do this sort of checking is by hacking into the
> tool that actually interprets it (i.e. lit in this case). Considering
> that lit is Python, it should be pretty easy to insert an ad-hoc regex
> check (or even something substantially more sophisticated). E.g.
> insert code into TestRunner.py's
2014 Jun 06
2
[LLVMdev] buildbot failure in LLVM on sanitizer-x86_64-linux (-Wframe-larger-than)
On 06/06/2014 02:33, Alexey Samsonov wrote:
> Hi Alp,
>
> This warning should be fixed by r210301. However, consider
> investigating why the frame size appears to be that large. I believe
> we build this code with GCC as well and have seen no complaints
> from its implementation of -Wframe-larger-than.
CC'ing in llvmdev. Like Chandler said it could just be due to lack of
2014 Jun 25
2
[LLVMdev] Phabricator and private reviews
On 25/06/2014 21:03, Eli Bendersky wrote:
> On Wed, Jun 25, 2014 at 10:44 AM, Alp Toker <alp at nuanti.com
> <mailto:alp at nuanti.com>> wrote:
>
> For whatever reason, patches posted to the Phabricator website
> still aren't being sent to the mailing list, making it difficult
> for us to review them.
>
> I've raised this issue a couple
2013 Dec 11
3
[LLVMdev] [cfe-dev] Phabricator email
On 11 December 2013 17:35, Alp Toker <alp at nuanti.com> wrote:
> I noticed a few contributors have been landing patches without responding to
> my review comments.
Oh, that happened to me too, but it turns out you have to press the
"clowncopterize" after making comments inlilne, or Phabricator won't
publish them. You can see them, we can't.
cheers,
--renato
2014 Jun 25
12
[LLVMdev] Phabricator and private reviews
For whatever reason, patches posted to the Phabricator website still
aren't being sent to the mailing list, making it difficult for us to
review them.
I've raised this issue a couple of times in the last few weeks.
In practice this has a detrimental effect to the development workflow
because it means that code is being seen only by a small group of
individuals who have web accounts.
2014 Jan 31
7
[LLVMdev] [cfe-dev] Status of SEH?
On 30/01/2014 22:57, Daniel Berlin wrote:
> On Thu, Jan 30, 2014 at 2:34 PM, Alp Toker <alp at nuanti.com> wrote:
>> On 30/01/2014 22:06, Daniel Berlin wrote:
>>> Actually, the policy actually says the right thing, you removed a
>>> sentence, which says:
>>> "Please contact the oversight group for more details."
>>
>> To be clear, I