[Mono-list] [PATCH] BitVector32

[Miguel de Icaza]

Hello Andrew,

> No problem, I'll get that done in the next few days.  I'm mostly
> interested in the compiler, but I plan on doing some more class library
> stuff to get going.  I'll also send a seperate patch which will stop the
> compiler from aborting when it encounters overly large integer literals
> too.

Thanks, I would love to get such a patch.

> I noticed that the "make sure each case in a switch() ends in break" and
> the "make sure all control paths return an appropriately typed value"
> features both need the same control-flow analysis.  I intend to look at
> that too, but more for my own education rather than having any high
> probability of coding the whole thing.

Well, notice that currently we do handle the second case (make sure all
control paths return an appropriately typed value).  So I believe that
the switch code could use this information to its advantage.  But I have
to sit down and think a bit more about this.

Basically what this means is that a more complex framework for data flow
analysis is not required to handle this particular case (unless am
proved wrong).   A more complex framework is required to handle definite
assignment though (and btw, a BitVector is just what we need for this
;-)

> Firstly, what's the policy on the text in exceptions?  Should they match
> the M$ implementation?  I only ask this because while I was learning C# I
> misunderstood format specifiers but only got an unhelpfully generic "Bad
> format string" exception rather than, for example, "Bad width specifier in
> format string".  In general, should people be submitting patches to
> improve things like this or is there some Deeper Reason behind the choice
> of error messages.

We should try to have good error reports, so improvements in this area
are always welcome, and deviating from the Microsoft ones for the sake
of clarity will always be good.

> Secondly, how do you choose the compiler error number which gets passed to
> Report.Error()?  Again, I suspect you might be matching the M$ behaviour
> but I only have a linux box here so I can't check.

I am using the same error numbers that the Microsoft C# compiler emits,
this serves two purposes:

	* Reuse the on-line documentation for their errors until we have
	  our own documentation.

	* Make sure we catch all errors their compiler does by having 
	  a test case for each error we are supposed to report.

Miguel.