---- Reported by grompf@sublimeintervention.com 2006-05-16 16:55:16 MST ----

The following code compiles on MS.net and used to compile on mono:

unsafe class T{
        void B () {
                void *p;
                (int)*(int *)((int)p) = 0;
        }
}

mcs and gmcs now report:

t.cs(4,25): error CS0131: The left-hand side of an assignment or mutating operation must be a 
variable, property or indexer
Compilation failed: 1 error(s), 0 warnings

-g



---- Additional Comments From miguel@ximian.com 2006-05-16 19:10:34 MST ----

Which version used to build with Mono, what version are you running now?



---- Additional Comments From grompf@sublimeintervention.com 2006-05-16 20:27:45 MST ----

Its failing on HEAD (Revision: 60758)

I am unsure of the last working revision.  The bug was just reported to me today on 
infrequently recompiled code.  I'll try to binary search tomorrow

-g




---- Additional Comments From rharinath@novell.com 2006-05-17 06:32:28 MST ----

Hmm, no need to search :-)  I believe the patch that changed it was:

  2006-04-19  Raja R Harinath  <rharinath@novell.com>

	* expression.cs (Cast.ResolveLValue): Remove.  The result of a
	cast is never an lvalue.

Changing your code to:

  *(int *)((int)p) = 0;

i.e., removing the redundant (int) cast, makes it work.

Section 14.6.6 (Cast expressions) says: The result is always
classified as a value, even if E denotes a variable.

---

Now, either CSC is buggy, or there may be some funky cast
disambiguation rules that may make CSC treat your code as:

  (int) ( *(int*)((int)p) = 0 )

while we treat it as

  ( (int) ( *(int*)((int)p) ) ) = 0

If you really want to keep your code, with the redundant (int) cast, I
welcome you to fix mcs ;-)



---- Additional Comments From rharinath@novell.com 2006-05-17 06:48:33 MST ----

On further thought, I can't think of any straightforward way for a
disambiguation rule to parse the code other than how mcs does.  The
compiler has to _know_ that it's a cast as soon as it sees (int), and
it doesn't need any further lookahead.  Casts bind tighter than
assignment.

So, I'm changing this to NOTABUG.



---- Additional Comments From grompf@sublimeintervention.com 2006-05-17 10:23:12 MST ----

hari,

  I have changed the code that exposed this (in fact the "erroneous" cast was there because 
of a old mcs bug that required it a long time ago) but I personally disagree with NOTABUG.  
I know we dont bug track microsoft in every instance; but in the COMPILER?  We should be 
compiling the same code they do (in my opinion).

  Its a process desicion rather than a technical one; I just want to wave the flag that if they 
compile it; I think we probably should as well.

  Admittedly this is a edge case.

-g




---- Additional Comments From rharinath@novell.com 2006-05-17 10:57:56 MST ----

OK, I have a simple workaround that probably won't introduce new bugs.
 Lemme see if it's enough.

We already have quite a bit on the plate trying to make the compiler
handle correct code.  Bug-compatibility with CSC is low priority,
especially when it's disruptive to the codebase.




---- Additional Comments From miguel@ximian.com 2006-05-17 18:41:57 MST ----

Agreed with Hari.

In particular when there are known bugs that must be addressed.


Unknown operating system unknown. Setting to default OS "Other".