Bug 319232 (MONO76371) - [PATCH] NullReferenceException compiling NDoc
Summary: [PATCH] NullReferenceException compiling NDoc
Status: RESOLVED FIXED
Alias: MONO76371
Product: Mono: Compilers
Classification: Mono
Component: C# (show other bugs)
Version: 1.1
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Raja R Harinath
QA Contact: Mono Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-08 16:06 UTC by Gert Driesen
Modified: 2007-09-15 21:24 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wiest 2007-09-15 19:33:56 UTC


---- Reported by gert.driesen@pandora.be 2005-10-08 09:06:33 MST ----

MCS (svn head) throws a NullReferenceException when compiling NDoc:

Unhandled Exception: System.NullReferenceException: Object reference not
set to an instance of an object
in <0x00074> Mono.CSharp.TypeContainer:DoDefineMembers ()
in <0x00050> Mono.CSharp.TypeContainer:DefineMembers
(Mono.CSharp.TypeContainer container)
in <0x000dd> Mono.CSharp.RootContext:PopulateTypes ()
in <0x00ba5> Mono.CSharp.Driver:MainDriver (System.String[] args)
in <0x00041> Mono.CSharp.Driver:Main (System.String[] args)

This is a regression as NDoc used to compile just fine.

To reproduce this issue, execute the following shell script (from a temp dir):

#!/bin/sh
export CVSROOT=:pserver:anonymous@cvs.sourceforge.net:/cvsroot/nant
cvs co nant
export CVSROOT=:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ndoc
cvs co ndoc
cd nant
make build-bootstrap
mono bootstrap/NAnt.exe -t:mono-1.0 build
cd ..
cd ndoc
mono ../nant/build/mono-1.0.unix/nant-0.85-debug/bin/NAnt.exe -t:mono-1.0



---- Additional Comments From miguel@ximian.com 2005-10-14 17:21:08 MST ----

This is a self contained test case:

using System.ComponentModel;

public class PropertySorter : ExpandableObjectConverter {
}

[TypeConverter(typeof(PathItemBase.TypeConverter))]
class PathItemBase {
	internal class TypeConverter : PropertySorter {
	}
}

class X {
	static void Main () {}
}

The problem is that the attribute [TypeConverter()] is referencing the
nested PathItemBase.TypeConverter.



---- Additional Comments From miguel@ximian.com 2005-10-14 17:49:34 MST ----

Ok, the problem is that the GetObsoleteAttribute call in
class.cs:1248 (TypeContainer.DefineType) is triggering a definition of
all the attributes, which "queues" the nested class for definition
ahead of the container type.

I moved the checking of the attributes after the order for a class has
been registered and this seems to help, but in general the type
registration framework should probably take containing types into
account, something that it does not do today.

I am hoping that we can get some feedback from the compiler developers
on this.  CCing them.   Here is a patch that seems to fix this:

Index: class.cs
===================================================================
--- class.cs    (revision 51728)
+++ class.cs    (working copy)
@@ -1279,14 +1279,6 @@
                                TypeBuilder.SetParent (ptype);
                        }

-                       // Attribute is undefined at the begining of
corlib compilation
-                       if (TypeManager.obsolete_attribute_type != null) {
-                              
TypeResolveEmitContext.TestObsoleteMethodUsage = GetObsoleteAttribute
() == null;
-                               if (ptype != null &&
TypeResolveEmitContext.TestObsoleteMethodUsage) {
-                                       CheckObsoleteType (base_type);
-                               }
-                       }
-
                        // add interfaces that were not added at type
creation
                        if (iface_exprs != null) {
                                // FIXME: I think this should be
...ExpandInterfaces (Parent.EmitContext, ...).
@@ -1307,6 +1299,14 @@
                        if (!(this is Iterator))
                                RootContext.RegisterOrder (this);

+                       // Attribute is undefined at the begining of
corlib compilation
+                       if (TypeManager.obsolete_attribute_type != null) {
+                              
TypeResolveEmitContext.TestObsoleteMethodUsage = GetObsoleteAttribute
() == null;
+                               if (ptype != null &&
TypeResolveEmitContext.TestObsoleteMethodUsage) {
+                                       CheckObsoleteType (base_type);
+                               }
+                       }
+
                        if (!DefineNestedTypes ()) {
                                error = true;
                                return null;




---- Additional Comments From rharinath@novell.com 2005-10-18 08:40:47 MST ----

I'm working on an alternate patch that should fix the bug, and clarify
the issue.



---- Additional Comments From rharinath@novell.com 2005-10-18 10:45:05 MST ----

Should be fixed in SVN r51864.



---- Additional Comments From rharinath@novell.com 2005-10-26 12:44:14 MST ----

*** https://bugzilla.novell.com/show_bug.cgi?id=MONO75630 has been marked as a duplicate of this bug. ***


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