On Sun, Nov 4, 2018 at 11:36 PM Tim van Deurzen wrote:
> I've received a lot of good advice from Nathan, but haven't had an
> opportunity to apply it yet. I'm happy, however, to show / commit what I
> have so far (which covers the parsing of the operator). I've been
> working from the git reposito
Will take care of it this evening then. If I get stuck or need some help
I'll try the IRC channel or reply to this mail again :).
Tim.
On 11/5/18 8:40 AM, Jakub Jelinek wrote:
On Mon, Nov 05, 2018 at 08:36:44AM +0100, Tim van Deurzen wrote:
I've received a lot of good advice from Nathan, but
On Mon, Nov 05, 2018 at 08:36:44AM +0100, Tim van Deurzen wrote:
> I've received a lot of good advice from Nathan, but haven't had an
> opportunity to apply it yet. I'm happy, however, to show / commit what I
> have so far (which covers the parsing of the operator). I've been working
> from the git
Hi Jason,
I've received a lot of good advice from Nathan, but haven't had an
opportunity to apply it yet. I'm happy, however, to show / commit what I
have so far (which covers the parsing of the operator). I've been
working from the git repository until now, but from the mailing list I
gather
On Wed, Sep 26, 2018 at 11:00 AM Jason Merrill wrote:
>
> On Mon, Sep 3, 2018 at 5:04 PM, Tim van Deurzen wrote:
> > I must confess that in the last months I've not been able to find much time
> > (I do this in my spare time) to work on this. Part of the problem is also
> > that my new employer h
On 9/26/18 8:00 AM, Jason Merrill wrote:
On Mon, Sep 3, 2018 at 5:04 PM, Tim van Deurzen wrote:
I must confess that in the last months I've not been able to find much time
(I do this in my spare time) to work on this. Part of the problem is also
that my new employer hasn't yet provided a writte
On Mon, Sep 3, 2018 at 5:04 PM, Tim van Deurzen wrote:
> I must confess that in the last months I've not been able to find much time
> (I do this in my spare time) to work on this. Part of the problem is also
> that my new employer hasn't yet provided a written copyright waiver for the
> FSF, thou
Hello Jakub,
I must confess that in the last months I've not been able to find much
time (I do this in my spare time) to work on this. Part of the problem
is also that my new employer hasn't yet provided a written copyright
waiver for the FSF, though they have agreed and my contract already
w
On Thu, Aug 30, 2018 at 08:07:05PM +0200, Jakub Jelinek wrote:
> On Thu, Jan 11, 2018 at 02:06:06PM +, Joseph Myers wrote:
> > On Thu, 11 Jan 2018, David Brown wrote:
> >
> > > Maybe it is easier to say "gcc supports <=> in C++2a, and as an
> > > extension also supports it in C and C++ of any
On Thu, Jan 11, 2018 at 02:06:06PM +, Joseph Myers wrote:
> On Thu, 11 Jan 2018, David Brown wrote:
>
> > Maybe it is easier to say "gcc supports <=> in C++2a, and as an
> > extension also supports it in C and C++ of any standard" ? I don't
> > believe there is any way for it to conflict with
On Thu, 11 Jan 2018, David Brown wrote:
> Maybe it is easier to say "gcc supports <=> in C++2a, and as an
> extension also supports it in C and C++ of any standard" ? I don't
> believe there is any way for it to conflict with existing valid code, so
> it would do no harm as a gcc extension like t
On 11/01/18 12:32, Jonathan Wakely wrote:
> On 11 January 2018 at 11:28, David Brown wrote:
>> On 11/01/18 11:13, Jonathan Wakely wrote:
>>> t all cleaOn 11 January 2018 at 10:05, David Brown wrote:
Maybe it is easier to say "gcc supports <=> in C++2a, and as an
extension also supports it
On 11 January 2018 at 11:32, Jonathan Wakely wrote:
> On 11 January 2018 at 11:28, David Brown wrote:
>> On 11/01/18 11:13, Jonathan Wakely wrote:
>>> t all cleaOn 11 January 2018 at 10:05, David Brown wrote:
Maybe it is easier to say "gcc supports <=> in C++2a, and as an
extension also s
On 11 January 2018 at 11:28, David Brown wrote:
> On 11/01/18 11:13, Jonathan Wakely wrote:
>> t all cleaOn 11 January 2018 at 10:05, David Brown wrote:
>>> Maybe it is easier to say "gcc supports <=> in C++2a, and as an
>>> extension also supports it in C and C++ of any standard" ? I don't
>>> be
On 11/01/18 11:13, Jonathan Wakely wrote:
> t all cleaOn 11 January 2018 at 10:05, David Brown wrote:
>> Maybe it is easier to say "gcc supports <=> in C++2a, and as an
>> extension also supports it in C and C++ of any standard" ? I don't
>> believe there is any way for it to conflict with existin
On 11 January 2018 at 10:13, Jonathan Wakely wrote:
> t all cleaOn 11 January 2018 at 10:05, David Brown wrote:
>> Maybe it is easier to say "gcc supports <=> in C++2a, and as an
>> extension also supports it in C and C++ of any standard" ? I don't
>> believe there is any way for it to conflict wi
t all cleaOn 11 January 2018 at 10:05, David Brown wrote:
> Maybe it is easier to say "gcc supports <=> in C++2a, and as an
> extension also supports it in C and C++ of any standard" ? I don't
> believe there is any way for it to conflict with existing valid code, so
> it would do no harm as a gcc
On 10/01/18 14:00, Jonathan Wakely wrote:
> On 9 Jan 2018 10:56 p.m., "Tim van Deurzen" wrote:
>
>
> Just to confirm with you, it does make sense to conditionally parse the
> token for operator<=> in libcpp (i.e. only when the cxx standard being used
> is >=2a)? I'm just wondering if this does n
Hi Jakub,
On 01/10/2018 10:32 PM, Jakub Jelinek wrote:
On Wed, Jan 10, 2018 at 10:24:00PM +0100, Tim van Deurzen wrote:
On 01/10/2018 02:00 PM, Jonathan Wakely wrote:
On 9 Jan 2018 10:56 p.m., "Tim van Deurzen" wrote:
Just to confirm with you, it does make sense to conditionally
On Wed, Jan 10, 2018 at 10:24:00PM +0100, Tim van Deurzen wrote:
> On 01/10/2018 02:00 PM, Jonathan Wakely wrote:
>
> > On 9 Jan 2018 10:56 p.m., "Tim van Deurzen" wrote:
> >
> >
> > Just to confirm with you, it does make sense to conditionally
> > parse the token for operator<=> in libc
On 01/10/2018 02:00 PM, Jonathan Wakely wrote:
On 9 Jan 2018 10:56 p.m., "Tim van Deurzen" wrote:
Just to confirm with you, it does make sense to conditionally
parse the token for operator<=> in libcpp (i.e. only when the cxx
standard being used is >=2a)? I'm just wondering if this
On 9 Jan 2018 10:56 p.m., "Tim van Deurzen" wrote:
Just to confirm with you, it does make sense to conditionally parse the
token for operator<=> in libcpp (i.e. only when the cxx standard being used
is >=2a)? I'm just wondering if this does not accidentally affect other
front-ends using libcpp?
On 01/08/2018 11:28 PM, Jason Merrill wrote:
On Mon, Jan 8, 2018 at 5:13 PM, Jonathan Wakely wrote:
On 8 January 2018 at 22:07, Jason Merrill wrote:
On Mon, Jan 8, 2018 at 4:07 PM, Tim van Deurzen wrote:
I've been spending some time the past few weeks implementing p0515r2,
i.e. the proposa
On 01/08/2018 05:07 PM, Jason Merrill wrote:
On Mon, Jan 8, 2018 at 4:07 PM, Tim van Deurzen wrote:
There's a gccint.info documentation file, the Options node seems like
what you're looking for. You will want to add a new option to
c-family/c.opt.
diffing between branches/c++-modules and t
On 01/08/2018 02:07 PM, Tim van Deurzen wrote:
Hi,
I've been spending some time the past few weeks implementing p0515r2,
i.e. the proposal for consistent comparisons for C++ (aka the spaceship
operator). I've received some very valuable help on the IRC channel, but
I'm still a little bit stuck.
On Mon, Jan 8, 2018 at 5:13 PM, Jonathan Wakely wrote:
> On 8 January 2018 at 22:07, Jason Merrill wrote:
>> On Mon, Jan 8, 2018 at 4:07 PM, Tim van Deurzen wrote:
>>> I've been spending some time the past few weeks implementing p0515r2,
>>> i.e. the proposal for consistent comparisons for C++ (a
On 8 January 2018 at 22:07, Jason Merrill wrote:
> On Mon, Jan 8, 2018 at 4:07 PM, Tim van Deurzen wrote:
>> I've been spending some time the past few weeks implementing p0515r2,
>> i.e. the proposal for consistent comparisons for C++ (aka the spaceship
>> operator).
>
> Great!
>
>> I've received
On Mon, Jan 8, 2018 at 4:07 PM, Tim van Deurzen wrote:
> I've been spending some time the past few weeks implementing p0515r2,
> i.e. the proposal for consistent comparisons for C++ (aka the spaceship
> operator).
Great!
> I've received some very valuable help on the IRC channel, but
> I'm still
28 matches
Mail list logo
