On Tue, 7 Feb 2017, Marek Polacek wrote:
> Fixed.
Here is a small follow-up patch that I applied on top of this.
It uses , improves markup, and simplifies language a bit.
(Note that if we have "member" is a meta-variable, then we also need
to mark it up as "member" whenever we refer to it.)
Ger
On Sun, Feb 12, 2017 at 09:08:42AM +0100, Gerald Pfeifer wrote:
> On Wed, 8 Feb 2017, Marek Polacek wrote:
> > Like this?
>
> As a consequence, the following examples are invalid and G++ will no longer
> -compile them:
> +compile them, because, in the following examples, G++ used to treat
> +this
On Wed, 8 Feb 2017, Marek Polacek wrote:
> Like this?
As a consequence, the following examples are invalid and G++ will no longer
-compile them:
+compile them, because, in the following examples, G++ used to treat
+this->member where member has a non-dependent type, as
+type-dependent, and now it
On Wed, Feb 8, 2017 at 12:45 PM, Marek Polacek wrote:
> On Wed, Feb 08, 2017 at 02:14:14PM +0100, Markus Trippelsdorf wrote:
>> I'm not suggesting to drop both. But:
>>
>> »As a consequence, the following examples are invalid and G++ will no
>> longer compile them, because, in the following exampl
On Wed, Feb 08, 2017 at 02:14:14PM +0100, Markus Trippelsdorf wrote:
> I'm not suggesting to drop both. But:
>
> »As a consequence, the following examples are invalid and G++ will no
> longer compile them, because, in the following examples, G++ used to...«
>
> The second occurrence of "the follo
On 2017.02.08 at 13:56 +0100, Marek Polacek wrote:
> On Wed, Feb 08, 2017 at 12:54:44PM +0100, Markus Trippelsdorf wrote:
> > On 2017.02.08 at 12:05 +0100, Marek Polacek wrote:
> > > On Tue, Feb 07, 2017 at 04:17:48PM -0500, Jason Merrill wrote:
> > > > On Tue, Feb 7, 2017 at 9:13 AM, Jonathan Wake
On Wed, Feb 08, 2017 at 12:54:44PM +0100, Markus Trippelsdorf wrote:
> On 2017.02.08 at 12:05 +0100, Marek Polacek wrote:
> > On Tue, Feb 07, 2017 at 04:17:48PM -0500, Jason Merrill wrote:
> > > On Tue, Feb 7, 2017 at 9:13 AM, Jonathan Wakely
> > > wrote:
> > > > On 07/02/17 15:04 +0100, Marek Po
On 2017.02.08 at 12:05 +0100, Marek Polacek wrote:
> On Tue, Feb 07, 2017 at 04:17:48PM -0500, Jason Merrill wrote:
> > On Tue, Feb 7, 2017 at 9:13 AM, Jonathan Wakely wrote:
> > > On 07/02/17 15:04 +0100, Marek Polacek wrote:
> > >>
> > >> Thanks much for the review. Looks ok now?
> >
> > I'd s
On Tue, Feb 07, 2017 at 04:17:48PM -0500, Jason Merrill wrote:
> On Tue, Feb 7, 2017 at 9:13 AM, Jonathan Wakely wrote:
> > On 07/02/17 15:04 +0100, Marek Polacek wrote:
> >>
> >> Thanks much for the review. Looks ok now?
>
> I'd suggest adding something to say that the reason these are now
> be
On Tue, Feb 7, 2017 at 9:13 AM, Jonathan Wakely wrote:
> On 07/02/17 15:04 +0100, Marek Polacek wrote:
>>
>> Thanks much for the review. Looks ok now?
I'd suggest adding something to say that the reason these are now
being diagnosed is that G++ used to treat e.g. this->member, where
member has a
On 07/02/17 15:04 +0100, Marek Polacek wrote:
Thanks much for the review. Looks ok now?
Looks great.
On Tue, Feb 07, 2017 at 01:44:44PM +, Jonathan Wakely wrote:
> On 07/02/17 14:27 +0100, Marek Polacek wrote:
> > > You could drop the namespace. Also "struct A" would be better, because
> > > otherwise fn1 is a private and thus unaccessible in fn2.
> >
> > True. So how about this extended ver
On 07/02/17 14:27 +0100, Marek Polacek wrote:
You could drop the namespace. Also "struct A" would be better, because
otherwise fn1 is a private and thus unaccessible in fn2.
True. So how about this extended version, which also mentions more examples
of what might now fail?
Index: porting_to.h
> You could drop the namespace. Also "struct A" would be better, because
> otherwise fn1 is a private and thus unaccessible in fn2.
True. So how about this extended version, which also mentions more examples
of what might now fail?
Index: porting_to.html
=
On Mon, Feb 06, 2017 at 03:00:38PM -0500, Nathan Sidwell wrote:
> On 02/06/2017 01:03 PM, Jason Merrill wrote:
>
> > No, this is a bug.
>
> Yup.
I've opened PR79393.
Marek
On 02/06/2017 01:03 PM, Jason Merrill wrote:
No, this is a bug.
Yup.
--
Nathan Sidwell
On 2017.02.06 at 18:13 +0100, Marek Polacek wrote:
> This patch adds a description of something I noticed while doing the
> Fedora mass rebuild. Do we want to say more about the invalidity of
> the incomplete type case?
> +
> +GCC 7 no longer accepts ill-formed code involving use of an incomplete
On Mon, Feb 6, 2017 at 12:13 PM, Marek Polacek wrote:
> This patch adds a description of something I noticed while doing the
> Fedora mass rebuild. Do we want to say more about the invalidity of
> the incomplete type case?
Here's the relevant rule in the standard:
14.6/8: "If a hypothetical ins
This patch adds a description of something I noticed while doing the
Fedora mass rebuild. Do we want to say more about the invalidity of
the incomplete type case?
Furthermore I noticed that the testcase below doesn't compile anymore since
r240874; Nathan, is that desirable?
class C {
public:
19 matches
Mail list logo
