[nem-bug] [Nemerle 0000701]: [0.9.3] Empty structs have $PLACE_HOLDER$ field

Sun Jul 2 16:12:41 CEST 2006

A NOTE has been added to this issue.
======================================================================
<http://nemerle.org/bugs/view.php?id=701> 
======================================================================
Reported By:                Snaury
Assigned To:                nazgul
======================================================================
Project:                    Nemerle
Issue ID:                   701
Category:                   Compiler
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     feedback
======================================================================
Date Submitted:             07-01-2006 16:05 CEST
Last Modified:              07-02-2006 16:12 CEST
======================================================================
Summary:                    [0.9.3] Empty structs have $PLACE_HOLDER$ field
Description: 
The following code:

  public struct EmptyStruct { }

produces empty structure with the following IL:

.class public sequential ansi sealed beforefieldinit EmptyStruct
       extends [mscorlib]System.ValueType
{
  .pack 0
  .size 1
} // end of class EmptyStruct

Nemerle's generated structure has no the following IL:

.class public auto ansi sealed EmptyStruct
       extends [mscorlib]System.ValueType
{
  .field private specialname uint8 $PLACE_HOLDER$
} // end of class EmptyStruct

As you can see, they differ and Nemerle's IL has strange $PLACE_HOLDER$
field. If possible, it would be good if generated code would be without
this $PLACE_HOLDER$ field...
======================================================================

----------------------------------------------------------------------
 nazgul - 07-01-06 21:26 
----------------------------------------------------------------------
AFAIR as added this field to mimick the C# compiler. But maybe has changed
after .NET 1.1 or it was mono compiler's behaviour. It must be checked if
this is still needed.

----------------------------------------------------------------------
 nazgul - 07-02-06 12:56 
----------------------------------------------------------------------
After using a patch I get verification error for empty structs:

bash-3.00$ ../../tools/verify out.exe 

[MD]: Error: ClassLayout has parent TypeDef token=0x02000002 marked
AutoLayout. [token:0x00000001]
1 Error Verifying out.exe

I'm investigating the possible fix.

----------------------------------------------------------------------
 Snaury - 07-02-06 13:11 
----------------------------------------------------------------------
Seems like after that class needs to be marked Sequential. I don't yet know
how type lookup in compiler works, though, so I don't know how a
StructLayout custom attribute can be applied on that struct...

----------------------------------------------------------------------
 nazgul - 07-02-06 13:15 
----------------------------------------------------------------------
At the stage of emitting hierarchy by S.R.E we can just define this
attribute using  code similar to make_nemerle_variant_attribute  in
HierarchyEmitter.n

----------------------------------------------------------------------
 nazgul - 07-02-06 13:46 
----------------------------------------------------------------------
I enchanced the patch and commited it, thanks!

Fixed on trunk (r6416).

----------------------------------------------------------------------
 Snaury - 07-02-06 15:28 
----------------------------------------------------------------------
Unless it's not too late, by occasion I found that you don't need to apply
attribute to achieve sequential layout, plus I found that both mcs and c#
default to sequential layout for structs (which can later be overriden by
applying attribute in user code). Besides, I found a way to better mimick
mcs behaviour, in regard for example to beforefieldinit flag (set
beforefieldinit when there is no static constructor). I'll attach new
patch against r6417.

----------------------------------------------------------------------
 nazgul - 07-02-06 15:41 
----------------------------------------------------------------------
Shouldn't it be Static  in the GetConstructor call? Do you have the exact
reference to specification, when beforefieldinit is emitted?

----------------------------------------------------------------------
 Snaury - 07-02-06 15:52 
----------------------------------------------------------------------
Actually yes, it should have been static (typo), but for some reason static
doesn't work there and throws (I'm trying to figure out why). :-/ I don't
have specification, but looking at mcs sources I see that they do it when
there is no default constructor, ms c# *seems* to do the same, I don't
know though. I think it's not even about specification, it's about
optimization, because if there is no static constructor -> there is no
initialization of fields -> we shouldn't request runtime to initialize
class upon first static call.

----------------------------------------------------------------------
 Snaury - 07-02-06 16:12 
----------------------------------------------------------------------
As for specification, see 10.5.3.2 of Ecma-335, it says about expences of
making sure that guaranties in 10.5.3.1 are met. But anyway, it's not
related to this bug, so maybe it would be a feature request (especially as
I still can't make GetConstructors work). Just exclude that part from the
patch.

Issue History
Date Modified  Username       Field                    Change              
======================================================================
07-01-06 16:05 Snaury         New Issue                                    
07-01-06 20:30 Snaury         File Added: bug-placeholder.patch                 

07-01-06 21:26 nazgul         Note Added: 0001331                          
07-02-06 12:56 nazgul         Note Added: 0001334                          
07-02-06 13:11 Snaury         Note Added: 0001335                          
07-02-06 13:15 nazgul         Note Added: 0001336                          
07-02-06 13:46 nazgul         Status                   new => resolved     
07-02-06 13:46 nazgul         Resolution               open => fixed       
07-02-06 13:46 nazgul         Assigned To               => nazgul          
07-02-06 13:46 nazgul         Note Added: 0001337                          
07-02-06 13:46 nazgul         Description Updated                          
07-02-06 15:28 Snaury         Status                   resolved => feedback
07-02-06 15:28 Snaury         Resolution               fixed => reopened   
07-02-06 15:28 Snaury         Note Added: 0001340                          
07-02-06 15:28 Snaury         Description Updated                          
07-02-06 15:29 Snaury         File Added: bug-placeholder-2.patch               

07-02-06 15:41 nazgul         Note Added: 0001341                          
07-02-06 15:52 Snaury         Note Added: 0001342                          
07-02-06 16:12 Snaury         Note Added: 0001343                          
======================================================================