[Mono-bugs] [Bug 73485][Nor] Changed - Flow analysis missing on anonymous methods.

[bugzilla-daemon@bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by miguel@ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=73485

--- shadow/73485	2005-04-19 04:45:00.000000000 -0400
+++ shadow/73485.tmp.2937	2005-04-19 21:11:55.000000000 -0400
@@ -10,13 +10,13 @@
 Component: C#
 AssignedTo: miguel@ximian.com                            
 ReportedBy: dsilva@ccs.neu.edu               
 QAContact: mono-bugs@ximian.com
 TargetMilestone: ---
 URL: 
-Summary: Problem compiling recursive delegates
+Summary: Flow analysis missing on anonymous methods.
 
 Please fill in this template when reporting a bug, unless you know what you
 are doing.
 Description of Problem:
 
 Inconsistent C# compiler behavior (gmcs).
@@ -117,6 +117,64 @@
 
 
 
 ------- Additional Comments From rharinath@novell.com  2005-04-19 04:45 -------
 I think it may be using ToplevelBlock.Container instead of
 ToplevelBlock.Parent.
+
+------- Additional Comments From miguel@ximian.com  2005-04-19 21:11 -------
+This is a bug in mcs, but for the wrong reasons.
+
+The program pasted here is actually an invalid program.  Will explain
+in a second.
+
+* Currently:
+
+So the situation is that when you insert the variable declaration
+before the delegate, what happens is this:
+
+the "delegate () { }" is parsed in its entirety, creating internally a
+ToplevelBlock, and as part of this process, the new toplevel block is
+assigned a Parent that points to the current_block (at this point this
+is the Main toplevel block.
+
+Then, once the "m = delegate {}" is parsed, we call the
+"declare_local_variables" that will actually introduce "m" into the scope.
+
+We introduce variables into the scope by creating a new implicit block
+, and this is where the delegate ToplevelBlock should have pointed to
+if it is to resolve the name "m".
+
+So that is the bug source at this point.  Fixing it would require us
+to either re-link the parent at declare_local_variables.  Ideally we
+would create implicit blocks as the variables are declared, but the
+way our compiler works, I think that would be a world of pain (just
+because these blocks would be created from within expression parsing,
+am not thrilled about that).
+
+* Microsoft's
+
+Microsoft is doing flow analysis and in both cases (the working and
+failing cases) CSC reports `Use of unassigned variable WWWWWW'.
+
+* Short term fix:
+
+The user test case should be fixed to decouple the declaration from
+the initialization, like this:
+
+check_t m = null;
+m = delegate (...) { m (); }
+
+Notice that `m' is assigned in this case.
+
+So the bug is that mcs should now warn that the variable is not
+definitely assigned (it could be argued that it is, but software
+compiled with our compiler would not compile on MS).
+
+I think we need the help of Martin here to sort out the flow analysis
+issues.  Sadly when he helped me, he helped me on the old codebase of
+anonymous methods, and in the rewrite I lost some of it.
+
+We still would have to fix the problem indicated before just to get
+flow analysis working correctly, but it is a lower priority issue.
+
+