[M3commit] CVS Update: cm3

[Jay K]

The backend should be able to cope with almost anything, I guess.

But is the source code really legal?

Shouldn't the front end error?

The front end should error on some things, obviously.

 

Notice that all of the "internal errors" in this scenario are from

the front end. Just the assertion failure is not.

 

 

The front end doesn't handle its own stack correctly

here, the errors come from its CG.m3 module that wraps

the backend.

 

If this code is truly illegal and has no valid meaning, I think this is an ok change.

The NT386 backend I guess should be hardened against front end bugs though.

 

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Tue, 2 Feb 2010 12:19:16 -0500
To: jkrell at elego.de
CC: m3commit at elegosoft.com
Subject: Re: [M3commit] CVS Update: cm3

That's the wrong approach.  A warning is not an error.  The backend should be able to cope with it...



Antony Hosking | Associate Professor | Computer Science | Purdue University


305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484



On 1 Feb 2010, at 20:17, Jay Krell wrote:

CVSROOT: /usr/cvs
Changes by: jkrell at birch. 10/02/01 20:17:28

Modified files:
cm3/m3-sys/m3front/src/values/: Variable.m3 

Log message:
test case e0\e029:

MODULE Main;
TYPE Rec = RECORD a: INTEGER END;
VAR  r := Rec;    (* warning: variable has type NULL *)
BEGIN
INC(r.a)
END Main.

followed by internal errors and an assertion failure in m3back

Change warning to error, and then it never gets to the internal errors.

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100203/17620593/attachment-0002.html>