Created attachment 786 [details]
test code

By the way, you have just shown the right way to design (or test) a language: you need to test all the items in the matrix/tensor of all possible combinations. One of the the inventor of Java did the same.

This code should not work.
----
interface I
{
    void set(int v);
}
class A : I
{
    this(int v){val = v;}
    int val = 10;
    override void set(int v){val = v;}
}
void change(I i)
{
    i.set(100);
}
void main()
{
    auto a = new immutable(A)(10);
    assert(a.val == 10);
    change(a);              // immutable(A) is converted to (mutable) I.
    assert(a.val == 100);   // breaking const-correctness!
}
----

Created attachment 787 [details]
test code(fixed)

test code fixed.
I withdraw part 1 and 2.

test code result is follows:
----
part1 ----
true,   false,  false,  false,  false
true,   true,   false,  false,  true
false,  false,  true,   false,  false
false,  false,  true,   true,   true
false,  false,  false,  false,  true
part2 ----
true,   false,  false,  false,  false
true,   true,   false,  false,  true
false,  false,  true,   false,  false
false,  false,  true,   true,   true
false,  false,  false,  false,  true
part3 ----
true,   true,   true,   true,   true
true,   true,   true,   true,   true
true,   true,   true,   true,   true
true,   true,   true,   true,   true
true,   true,   true,   true,   true
----

Created attachment 788 [details]
Patch for DMD svn r716

(In reply to comment #3)
> interface I
> {
>     void set(int v);
> }
> class A : I
> {
>     this(int v){val = v;}
>     int val = 10;
>     override void set(int v){val = v;}
> }
> void change(I i)
> {
>     i.set(100);
> }
> void main()
> {
>     auto a = new immutable(A)(10);
>     assert(a.val == 10);
>     change(a);              // immutable(A) is converted to (mutable) I.
>     assert(a.val == 100);   // breaking const-correctness!
> }

Looks like duplicate of bug 3731 (read Steven's comment).

Mass migration of bugs marked as x86-64 to just x86.  The platform run on isn't what's relevant, it's if the app is a 32 or 64 bit app.

The patch causes this code to fail to compile:
----
class S { }

void main()
{
    S s1 = new S;
    const S s2 = new S;
    assert(s1!=s2);
}
---
Even so, I think the patch is probably correct -- it's a problem with opEquals.
But this means that more work is required before this patch could be applied.

(In reply to comment #8)
> The patch causes this code to fail to compile:
> ----
> class S { }
> 
> void main()
> {
>     S s1 = new S;
>     const S s2 = new S;
>     assert(s1!=s2);
> }
> ---
> Even so, I think the patch is probably correct -- it's a problem with opEquals.
> But this means that more work is required before this patch could be applied.

That code should fail to compile on the current compiler without patches, because the prototype for opEquals for objects is:

bool opEquals(Object lhs, Object rhs);

Clearly, this should not accept any const objects.  Because opEquals is special somehow, the compiler rams it through.

So yeah, that code is not indicative of the patch being bad.

*** This issue has been marked as a duplicate of issue 3731 ***