[DotGNU]CSHARP Compiler testing update

[James Michael DuPont]

Dear All,
Just a quick note on my status since I unfortunately missed the
meetathon.
I have used the new pdftohtml version to convert the ecma spec into
XML, had to patch it again a bit to have it work smoothly.
The XML files are then processed into snippets and passed to cscc and
csdoc. 
I have updated bison.simple and created bison.xml, this allows for a
dumping of the parse tree from bison.
The csdoc and cscc have hidden flags to turn on bison debugging,
I have activated them and with the xml enabled bison, you get a nice
xml dump of what the parser is doing. THis is great for automated
tests. I needed the encoding routine from html_doc.c, and I want to
move that out into a lib function. Also I was wondering if we will be
supporting DOM creation in memory ala libxml2? How many XML libs will
we support, and will the C model be able to inter operate in memory
with the C#?

Now the bison c# parser has some 514 rules, 911 states, I have a perl
script to process the dumped xml and extract out the parser states, the
rules and the tokens used by a snippet of code. 

This can then be used to make sure that we have a full test of the 
compiler internal states, and have a correlation between the test
numbers and the states of the compiler.

This and the test suite can show us what parts of the grammar are
having problems, what areas are well tested, and what parts have not
been tested at all. 

Also I will be creating a database of the error messages, explaining
what parse states created them, and how to fix them. This will help
create a automatic code refactoring and repair facility for C#
programs.
I can imagine someone just posting the code to a mailing list, and
having he analysis done and the results returned. That will also
eliminate any question of distribution of "dangerous" patches.

I have worked out a set of RDF-like predicates for describing the code
blocks found, not all are just code to compile :

1. SKIP- it is just a highlighted word in a text.
2. EXAMPLE should compile. No output specified.
3. EXAMPLE, use BLOCK X as the expected output.
4. EXAMPLE, should produce the same IL as BLOCK Y
5. FAIL, this example should not compile at all.
6. GRAMMAR, this is Grammar Code.
8. EXAMPLE, needs to be appended to Example N.
9. SHELL, this is what is entered into the command line.
10. IL, this is the expected IL output.
I think that this annotation can be added via an RDF file that is
distributed separately from the spec. That will avoid any copyright
violation.

Now for the complete generation of all test cases, I have found a good
too called RMUTT,
you feed it a yacc like grammar, and It will generate code for you.
when I get the time, I will patch the yacc, or parse the vcg output of
the yacc to output into rmutt, that will allow for automatic generation
of many test cases.

Of course these patches will not be distributed to the general public,
only after approval from rhys will anything be released to the general
public. But the results look promising. :)

I will not have too much time this week to work on it, 
but just wanted to let you know of my status.

Mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com