Bug 315645 (MONO62232) - We don't report cs0208
Summary: We don't report cs0208
Status: RESOLVED FIXED
Alias: MONO62232
Product: Mono: Compilers
Classification: Mono
Component: C# (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Enhancement
Target Milestone: ---
Assignee: Mono Bugs
QA Contact: Mono Bugs
URL:
Whiteboard:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2004-08-01 20:54 UTC by Ben Maurer
Modified: 2007-09-15 21:24 UTC (History)
1 user (show)

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


Attachments
proposed patch (3.30 KB, patch)
2004-09-30 06:35 UTC, Thomas Wiest
Details | Diff
updated patch (2.49 KB, patch)
2004-09-30 08:27 UTC, Thomas Wiest
Details | Diff
lucky number 3 (2.58 KB, patch)
2004-09-30 20:22 UTC, Thomas Wiest
Details | Diff
final one (2.78 KB, patch)
2004-09-30 22:42 UTC, Thomas Wiest
Details | Diff
updated again (2.53 KB, patch)
2004-12-30 08:12 UTC, Thomas Wiest
Details | Diff
patch (2.55 KB, patch)
2005-01-07 08:09 UTC, Thomas Wiest
Details | Diff

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


---- Reported by bmaurer@users.sf.net 2004-08-01 13:54:21 MST ----

This code should not compile:

unsafe struct X {
	string a;
	static void Main () {
		X x;
		X* y = &x;
	}
}

Microsoft (R) Visual C# .NET Compiler version 8.00.40426.16
for Microsoft (R) Windows (R) .NET Framework version 2.0.40426
Copyright (C) Microsoft Corporation 2001-2003. All rights reserved.
 
t.cs(5,3): error CS0208: Cannot take the address of, get the size of, or
declare a pointer to a managed type ('X')
t.cs(1,15): (Location of symbol related to previous error)
t.cs(5,10): error CS0208: Cannot take the address of, get the size of, or
declare a pointer to a managed type ('X')



---- Additional Comments From bmaurer@users.sf.net 2004-08-01 13:57:58 MST ----

From the spec:

`A pointer-type is written as an unmanaged-type or the keyword void,
followed by a *'

`An unmanaged-type is any type that isn't a reference-type and doesn't
contain reference-type fields at any level of nesting. In other words,
an  unmanaged-type is one of the following:
 
      * sbyte, byte, ... 
      * Any enum-type.
      * Any pointer-type. 
      * Any user-defined struct-type that contains fields of 
unmanaged-types only.'



---- Additional Comments From miguel@ximian.com 2004-08-03 12:48:50 MST ----

Yes, known bug. 

The problem is that TypeManager.VerifyUnManaged is not complete.





---- Additional Comments From jluke@cfl.rr.com 2004-09-29 23:35:59 MST ----

Created an attachment (id=166550)
proposed patch




---- Additional Comments From jluke@cfl.rr.com 2004-09-29 23:39:05 MST ----

The above catches that error, and a similar small test where it is an
inner struct that contains a managed field and can build all of our
libraries and mcs successfully.  I probably need more tests though, if
anyone has any advice as what to look for.

Basically I just fixed the existing IsUnmanagedType according to the
spec 25.2 and call that from VerifyUnManaged.



---- Additional Comments From bmaurer@users.sf.net 2004-09-30 00:27:15 MST ----

<jluke> so if you look at the patch, see the comment FIXME that I
removed, that is why I checked nested types
<jluke> why do you think it shouldn't
<BenM> struct X {
<BenM>    class Y {
<BenM>       object o;
<BenM>    }
<BenM> }
<BenM> X is still an unmanaged type i think
<jluke> can you test it with csc, I assumed that wouldn't be
<jluke> if not it is even easier
<BenM> my dad's windows box is off :-(
<BenM> ill do it tmw
<jluke> oh, well I can try it later, add a comment or something to the bug



---- Additional Comments From jluke@cfl.rr.com 2004-09-30 01:27:18 MST ----

Created an attachment (id=166551)
updated patch




---- Additional Comments From bmaurer@users.sf.net 2004-09-30 08:21:17 MST ----

In the GetFields part of the verifyunmanaged (you cant see it in the 
ctx here), you need to using BindingFlags.Public | 
BindingFlags.NonPublic



---- Additional Comments From jluke@cfl.rr.com 2004-09-30 13:22:02 MST ----

Created an attachment (id=166552)
lucky number 3




---- Additional Comments From bmaurer@users.sf.net 2004-09-30 15:10:04 MST ----

YOu can add bindingflags.static so that you dont have to do the if 
(.isstatic) test.



---- Additional Comments From jluke@cfl.rr.com 2004-09-30 15:42:33 MST ----

Created an attachment (id=166553)
final one




---- Additional Comments From duncan@ximian.com 2004-12-29 08:52:57 MST ----

Could this be committed?



---- Additional Comments From bmaurer@users.sf.net 2004-12-29 23:14:24 MST ----

-FieldInfo [] fields = t.GetFields ();
+FieldInfo [] fields = t.GetFields (BindingFlags.Public |
BindingFlags.NonPublic | BindingFlags.Static);

That needs to be .Instance. My mistake for giving you bad info ;-).

-if (f.FieldBuilder.IsStatic)
+if (f.FieldBuilder == null || f.FieldBuilder.IsStatic)

I am sure I asked this before, but can you tell me what == null means
here?

With the fix and an expl for the == null, I think I have reviewed this
to death. Miguel, any comments?



---- Additional Comments From jluke@cfl.rr.com 2004-12-30 01:09:23 MST ----

"-if (f.FieldBuilder.IsStatic)
+if (f.FieldBuilder == null || f.FieldBuilder.IsStatic)

I am sure I asked this before, but can you tell me what == null means
here?"

I don't recall more than it is possible for it to be null there (just
as the test for null immediately above it), someone more familiar with
mcs will have to have a look.  A fullbuild will fail without it.



---- Additional Comments From jluke@cfl.rr.com 2004-12-30 01:12:29 MST ----

Created an attachment (id=166554)
updated again




---- Additional Comments From jluke@cfl.rr.com 2005-01-07 01:08:31 MST ----

Regarding the fieldbuilder question, it still seems correct to me,
this looks related:
2004-12-30  Duncan Mak  <duncan@ximian.com>

    * typemanager.cs (TypeManager.CheckStructCycles): Don't crash here
    if field.FieldBuilder is null. Fixes #70758.

My last patch removed the IsStatic check in the wrong place, attaching
the latest version now.  Passes all tests, bootstraps, etc.



---- Additional Comments From jluke@cfl.rr.com 2005-01-07 01:09:35 MST ----

Created an attachment (id=166555)
patch




---- Additional Comments From duncan@ximian.com 2005-02-13 04:07:42 MST ----

Is this committable now?



---- Additional Comments From rharinath@novell.com 2005-02-15 08:07:07 MST ----

Looks good to me.



---- Additional Comments From jluke@cfl.rr.com 2005-02-18 13:36:51 MST ----

f-spot has some new code (libgphoto2-sharp) that this patch causes
compilation to fail, I'm not sure why yet.



---- Additional Comments From rharinath@novell.com 2005-04-05 03:20:54 MST ----

There were some changes to IsUnmanaged type that should solve the
f.FieldBuilder == null issue.  I think the patch has to be regenerated.

John Luke, do you have some time to look into this?  Otherwise I'll
try to tackle it.



---- Additional Comments From rharinath@novell.com 2005-04-05 10:32:19 MST ----

I adapted the patch and applied it to SVN.


Imported an attachment (id=166550)
Imported an attachment (id=166551)
Imported an attachment (id=166552)
Imported an attachment (id=166553)
Imported an attachment (id=166554)
Imported an attachment (id=166555)

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