Hi Paolo/All, New archive here:
http://homepage.ntlworld.com/james.purbrick/VerifierTests6.tar I've added tests for loading overlapped fields, boxing byref types and other exotica, tidied up the scripts so they are much clearer and simpler and fixed a load of tests. All the tests bar those which reference non-existent fields and methods now assemble with Mono ilasm and all the resultant exes give (only) the expected verification errors when run through MS peverify /IL (although MS peverify seems fine about stack merging native ints with int32s and loading initonly fields). > Would you mind extracting the IL template source in > their own files? Maybe something called > testtype.iltmpl. This way it's easier to look at > them. Hmm, I like having the templates in the scripts to keep them encapsulated and I think it's easier to keep the markers in the templates and substitution commands in sync that way. I've added some white space between the script commands and templates in the scripts though, so it's easier to see the CIL now. > Note that at least some templetes are invalid: > in make_bin_test.sh the signature of Main() is > parametrized, but this is not allowed, since only no > args or string[] is accepted. I think I've fixed this now. > The attached Makefile is what I temporarily use I don't think I got the attachment. I've hacked together some scripts for now. I'll leave the decision as to how you want to integrate the tests with the Mono SVN tree up to you. > Or, another option that would make testing much > faster: instead of having independent il programs, > make them compile to a library and generate a C# > driver program that calls each function with a try {} > catch (ExpectedException) {} clause. This can't be > done for all the tests, though ... It also makes it more difficult to run through other external verifiers or runtime verifiers which don't through the same exception. I think it's useful to be able to compare results from the different verifiers, so I think we should keep the tests as separate CIL files. > It is always possible to merge two references to > Object. This doesn't mean that the later uses of > this object are verifiable. Say that a callvirt is > done on the object to MyMethod (): this call won't > be verifiable, because Object doesn't define a > MyMethod () method. Hope this clears things up. Yes, thanks. I'm going to need a test that's a bit more involved than the current 10 line CIL snippets for this one... ;-) > Not sure what you mean by slot type. The type of the > target field/local/etc must be compatible with the > stack type of the values that is going to be stored > to it. Yes. I needed to read partition I to clear this up. I,8.7 says that values either need to be assignment compatible with locations or it needs to be possible to coerce the value so it is compatible. So, I need another set of tests for assignment compatibility. I'll do those tomorrow. Cheers, Jim. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list