4751 Regression(1.062, 2.047) ICE(constfold.c) >> after error
4753 fail_compilation/fail116.d sends dmd into a loop, exhausting memory
4771 fail_compilation/fail274.d hits a halt in iasm.c

I suggest we introduce a policy for compiler releases: "No regressions
more recent than 2.041/1.057".
We can gradually push this back until all regressions are gone.

On 31 August 2010 11:04, Don Clugston <dclugston at googlemail.com> wrote:
> 4751 Regression(1.062, 2.047) ICE(constfold.c) >> after error
> 4753 fail_compilation/fail116.d sends dmd into a loop, exhausting memory
> 4771 fail_compilation/fail274.d hits a halt in iasm.c
>
> I suggest we introduce a policy for compiler releases: "No regressions
> more recent than 2.041/1.057".
> We can gradually push this back until all regressions are gone.

There are two other regressions with patches:

4430 Regression(2.037) erroneous matching on specialized template function 3627 -of with a filename with a double extension confuses linker

If all those are fixed, we'll be down to 7 D2-specific regressions, 5 D1-specific regressions, and 2 which are common to both. (There are a couple of other bugs tagged as 'regression', but which have never actually worked correctly).

On 2 September 2010 09:58, Don Clugston <dclugston at googlemail.com> wrote:
> On 31 August 2010 11:04, Don Clugston <dclugston at googlemail.com> wrote:
>> 4751 Regression(1.062, 2.047) ICE(constfold.c) >> after error
>> 4753 fail_compilation/fail116.d sends dmd into a loop, exhausting memory
>> 4771 fail_compilation/fail274.d hits a halt in iasm.c
>>
>> I suggest we introduce a policy for compiler releases: "No regressions
>> more recent than 2.041/1.057".
>> We can gradually push this back until all regressions are gone.
>
> There are two other regressions with patches:
>
> 4430 Regression(2.037) erroneous matching on specialized template function 3627 -of with a filename with a double extension confuses linker
>
> If all those are fixed, we'll be down to 7 D2-specific regressions, 5 D1-specific regressions, and 2 which are common to both. (There are a couple of other bugs tagged as 'regression', but which have never actually worked correctly).
>

And I just created my most fun patch for a long time. Fixes 3 bugs at once. See bug 4173.

4173 Regression(2.037) Explicitly instantiated templates still try to
do IFTI in some cases
1715 Template specialization checks for equality rather than convertibility
1970 Templated interfaces not matched

I fixed the regression by allowing arbitrary type deduction of templated base classes and interfaces. This lets you do crazy stuff like this:

interface TwoWay(A,B) {}
class C1: TwoWay!(char, float), TwoWay!(int, float) {}
class C2: TwoWay!(float, char) {}
class C3 : C2, TwoWay!(int, char) {}

C1 twoway;
C3 twoway2;
B foo(A, B)(TwoWay!(A, B) x, TwoWay!(B, A) y) { return B.init;}

static assert(is(typeof(foo(twoway, twoway2)) == float));
static assert(is(typeof(foo(twoway2, twoway)) == char));

Long ago I filed a bug that has similar issues (1653), and found it was a duplicate of 1807.  It has some similar "magic" IFTI that your funky test case shows, can you see if your patch either fixes it or else if it is easy to include it too?

http://d.puremagic.com/issues/show_bug.cgi?id=1807

Thanks for the patch for 4173!

-Steve



----- Original Message ----
> From: Don Clugston <dclugston at googlemail.com>
> To: Discuss the internals of DMD <dmd-internals at puremagic.com>
> Sent: Fri, September 3, 2010 2:36:00 PM
> Subject: Re: [dmd-internals] Three patches for recent regressions
> 
> On 2 September 2010 09:58, Don Clugston <dclugston at googlemail.com>  wrote:
> > On 31 August 2010 11:04, Don Clugston <dclugston at googlemail.com>  wrote:
> >> 4751 Regression(1.062, 2.047) ICE(constfold.c) >> after  error
> >> 4753 fail_compilation/fail116.d sends dmd into a loop,  exhausting memory
> >> 4771 fail_compilation/fail274.d hits a halt in  iasm.c
> >>
> >> I suggest we introduce a policy for compiler  releases: "No regressions
> >> more recent than 2.041/1.057".
> >>  We can gradually push this back until all regressions are gone.
> >
> >  There are two other regressions with patches:
> >
> > 4430  Regression(2.037) erroneous matching on specialized template function
> >  3627 -of with a filename with a double extension confuses linker
> >
> >  If all those are fixed, we'll be down to 7 D2-specific regressions, 5
> >  D1-specific regressions, and 2 which are common to both. (There are a
> >  couple of other bugs tagged as 'regression', but which have never
> >  actually worked correctly).
> >
> 
> And I just created my most fun patch  for a long time. Fixes 3 bugs at once. See bug 4173.
> 
> 4173  Regression(2.037) Explicitly instantiated templates still try to
> do IFTI in  some cases
> 1715 Template specialization checks for equality rather than  convertibility
> 1970 Templated interfaces not matched
> 
> I fixed the  regression by allowing arbitrary type deduction of templated base classes and  interfaces. This lets you do crazy stuff like this:
> 
> interface  TwoWay(A,B) {}
> class C1: TwoWay!(char, float), TwoWay!(int, float)  {}
> class C2: TwoWay!(float, char) {}
> class C3 : C2, TwoWay!(int, char)  {}
> 
> C1 twoway;
> C3 twoway2;
> B foo(A, B)(TwoWay!(A, B) x, TwoWay!(B,  A) y) { return B.init;}
> 
> static assert(is(typeof(foo(twoway, twoway2)) ==  float));
> static assert(is(typeof(foo(twoway2, twoway)) ==  char));
> _______________________________________________
> dmd-internals  mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
> 

Is this functionality safe? It looks like there's some kind of type variance going on. I'm not sure when covariance and contravariance should be allowed with D templates.

Sent from my iPhone

On Sep 3, 2010, at 2:36 PM, Don Clugston <dclugston at googlemail.com> wrote:

> On 2 September 2010 09:58, Don Clugston <dclugston at googlemail.com> wrote:
>> On 31 August 2010 11:04, Don Clugston <dclugston at googlemail.com> wrote:
>>> 4751 Regression(1.062, 2.047) ICE(constfold.c) >> after error
>>> 4753 fail_compilation/fail116.d sends dmd into a loop, exhausting memory
>>> 4771 fail_compilation/fail274.d hits a halt in iasm.c
>>> 
>>> I suggest we introduce a policy for compiler releases: "No regressions
>>> more recent than 2.041/1.057".
>>> We can gradually push this back until all regressions are gone.
>> 
>> There are two other regressions with patches:
>> 
>> 4430 Regression(2.037) erroneous matching on specialized template function 3627 -of with a filename with a double extension confuses linker
>> 
>> If all those are fixed, we'll be down to 7 D2-specific regressions, 5 D1-specific regressions, and 2 which are common to both. (There are a couple of other bugs tagged as 'regression', but which have never actually worked correctly).
>> 
> 
> And I just created my most fun patch for a long time. Fixes 3 bugs at once. See bug 4173.
> 
> 4173 Regression(2.037) Explicitly instantiated templates still try to
> do IFTI in some cases
> 1715 Template specialization checks for equality rather than convertibility
> 1970 Templated interfaces not matched
> 
> I fixed the regression by allowing arbitrary type deduction of templated base classes and interfaces. This lets you do crazy stuff like this:
> 
> interface TwoWay(A,B) {}
> class C1: TwoWay!(char, float), TwoWay!(int, float) {}
> class C2: TwoWay!(float, char) {}
> class C3 : C2, TwoWay!(int, char) {}
> 
> C1 twoway;
> C3 twoway2;
> B foo(A, B)(TwoWay!(A, B) x, TwoWay!(B, A) y) { return B.init;}
> 
> static assert(is(typeof(foo(twoway, twoway2)) == float));
> static assert(is(typeof(foo(twoway2, twoway)) == char));
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 3 September 2010 21:04, Jason House <jason.james.house at gmail.com> wrote:
> Is this functionality safe? It looks like there's some kind of type variance going on. I'm not sure when covariance and contravariance should be allowed with D templates.

Where do you see covariance?

This is a change ONLY to type deduction. If you explicitly specify the
types, it already works in D1, and in D2 before the regression in
2.037.
I'm not sure what you mean by safe, but in cases where there is
ambiguity, it won't compile (that was most of the difficulty,
actually). And it can only match classes/interfaces from the
inheritance hierarchy. Can you come up with a scenario where it would
be a problem?

On Sep 3, 2010, at 3:24 PM, Don Clugston <dclugston at googlemail.com> wrote:

> On 3 September 2010 21:04, Jason House <jason.james.house at gmail.com> wrote:
>> Is this functionality safe? It looks like there's some kind of type variance going on. I'm not sure when covariance and contravariance should be allowed with D templates.
> 
> Where do you see covariance?
> 
> This is a change ONLY to type deduction. If you explicitly specify the
> types, it already works in D1, and in D2 before the regression in
> 2.037.
> I'm not sure what you mean by safe, but in cases where there is
> ambiguity, it won't compile (that was most of the difficulty,
> actually). And it can only match classes/interfaces from the
> inheritance hierarchy. Can you come up with a scenario where it would
> be a problem?

My mistake. That's some awful code. Do I understand it right that if the indirection through C2 is removed that this would become a compile error?

On 3 September 2010 22:01, Jason House <jason.james.house at gmail.com> wrote:
> My mistake. That's some awful code. Do I understand it right that if the indirection through C2 is removed that this would become a compile error?

Yes, it would be a compile error. And yes, it's foul. It was the most horrible example I could come up with <g>.

On Sep 3, 2010, at 4:13 PM, Don Clugston <dclugston at googlemail.com> wrote:

> On 3 September 2010 22:01, Jason House <jason.james.house at gmail.com> wrote:
>> My mistake. That's some awful code. Do I understand it right that if the indirection through C2 is removed that this would become a compile error?
> 
> Yes, it would be a compile error. And yes, it's foul. It was the most horrible example I could come up with <g>.

Tying into the other thread, will these become part of a test suite?

On 3 September 2010 22:16, Jason House <jason.james.house at gmail.com> wrote:
> On Sep 3, 2010, at 4:13 PM, Don Clugston <dclugston at googlemail.com> wrote:
>
>> On 3 September 2010 22:01, Jason House <jason.james.house at gmail.com> wrote:
>>> My mistake. That's some awful code. Do I understand it right that if the indirection through C2 is removed that this would become a compile error?
>>
>> Yes, it would be a compile error. And yes, it's foul. It was the most horrible example I could come up with <g>.
>
> Tying into the other thread, will these become part of a test suite?

Yes. I usually do it this way. Look in the test suite for ctorpowtests.d and the last thousand lines of interpret.d for some of my past examples of test-driven development. But most bugs I fix are just ICE or wrong-code bugs, which just need a single test case.