[Mono-devel-list] daily(?) /doc patches
Atsushi Eno
atsushi at ximian.com
Thu Aug 26 20:32:15 EDT 2004
Hello,
Marek Safar wrote:
> Hello,
>
> It looks that nothing from my previous recommendations has been accepted.
> In this stage is the patch too "buggy".
Mmm, sorry but it seems like I haven't received your mail. I haven't
seen the message.
Please post to the list as well.
I once wrote to you why I keep the patch as is, after receiving your
list of warnings numbers:
> Well, as for existing patch, Miguel has already reviewed and approved
> with some comments, immediate before I met breakage. So I'll first
> commit (if it is said OK) existing stuff without improving those
> errors. They will be improved on the second stage.
It is OK for me but not sure if I had better modify the patch heavily.
The last one seems not trivial though.
Atsushi Eno
>>Since we have missed almost all the chances to commit /doc patches
>>because it had been soon obsolete against the latest CVS HEAD, I
>>decided to put the patches here. If the patch is not applicable for
>>the latest HEAD, tell me and I'll make diff and upload it onto this
>>directory:
>>http://primates.ximian.com/~atsushi/mcs-doc-patches/
>>
>>I won't modify (and hadn't made) the change content of the patches.
>>
>>Atsushi Eno
>>
>>_______________________________________________
>>Mono-devel-list mailing list
>>Mono-devel-list at lists.ximian.com
>>http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>>
>>
>
>
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: [Mono-devel-list] the latest /doc patch
> From:
> Marek Safar <marek.safar at seznam.cz>
> Date:
> Tue, 10 Aug 2004 17:35:59 +0100
> To:
> Atsushi Eno <atsushi at ximian.com>
>
> To:
> Atsushi Eno <atsushi at ximian.com>
> CC:
> Martin Baulig <martin at ximian.com>, Miguel de Icaza <miguel at ximian.com>
>
>
> Hello Eno,
>
>> Hi,
>>
>> Since mcs got more stable than last week, I made the latest patch
>> for /doc support. I modified a bit (as Miguel asked me for the
>> previous patch; added some commends, removed --options) but basic
>> part of patch is unchanged.
>>
>> I have had no problem for a month or so since the last trouble
>> that prevented me from commiting the last ready-to-go patch.
>>
>> I also added some tests wrt doc comments. It however just tests
>> if it does not break compilation (i.e. not checking result docs).
>>
>>
> What is missing on the tests are test
> My suggestion is to create for every xml-???.cs also
> xml-???.xml.expected and add to every Main method test whether generated
> xml is same as expected.
> To be sure that this patch is still working with same results.
>
> Tip: Use "// Compiler options: " syntax for /doc compiler option
>
>> I've received a list of to-be-supported warning messages from
>> Marek (thanks to him) and those works will be done later.
>>
>>
>>
>>
> 1,
>
> Error message for 2006 should be better explanatory e.g. "Command-line
> syntax error: Missing ':<text>' for '/doc' switch"
>
> 2,
>
> You cannot write simple Report.Warning. You always have to test
> WarningLevel for your Warning. Use IF or Warning method with Message
> parameter.
>
> To Miguel: It is that I was talking about !
>
> + } catch (XmlException ex) {
> + Report.Warning (1570, Lexer.Location, "XML comment is not
> well-formed: " + ex.Message);
> + XmlComment com = doc.CreateComment ("FIXME: Invalid
> documentation markup was found for member " + fullyQualifiedName);
> + doc.DocumentElement.LastChild.AppendChild (com);
> + }
>
> +void WarnIncorrectXmlComment (string token_type)
> +{
> + Report.Warning (1587, Lexer.Location, "XML comment is not
> acceptable on " + token_type);
> + Lexer.ConsumeXmlComment ();
> }
>
> 3,
>
> For this cases can be better use StringBuilder or String.Format. It is
> extremely memory consuming especially on windows.
>
> + Documentation.SetAttribute ("name", "M:" + container.Name + "." +
> Name + "(" + para1 + (para2 != null ? "," + para2 : null) +
>
> or this
>
> + string paramSpec = null;
> + Parameter [] plist = Parameters.FixedParameters;
> + if (plist != null) {
> + foreach (Parameter p in plist)
> + paramSpec += (paramSpec != null ? "," : "(") +
> container.ResolveType (p.TypeName, false, Location).FullName;
> + }
>
> BTW: This code is really buggy. See point 6 for further hints and please
> be aware of FullName usage because it uses "+" instead of "." separator.
> You can use methods GetSignatureForError either we will have same
> troubles (like special handling for operators, indexers, ref & out
> params, __arglist params, etc...) twice because your code seems to do
> exactly same.
>
> Try this code
>
> public class Test
> {
> public class A {}
>
> public static void Main ()
> {
> }
>
> /// here is a documentation
> public static void Foo (A a)
> {
> }
> }
>
> 4,
> Why don't create for "M:", "F:" etc, some nice constants ?
>
> 5,
> This code generate buggy xml.
> BTW: your xml-017.cs test
>
> public class Test
> {
> public static void Main ()
> {
> }
>
> /// here is a documentation with parameters (and has same name)
> public static void Foo (params string [] param)
> {
> }
> }
>
> 6,
> The most important problem. Why do you call RootContext.FixupDocument ()
> before types are Defined. This is very dangerous and you will have to
> duplicate code what is in Define methods.
> And this simple code now crash compiler.
>
> public class Test
> {
> /// here is a documentation with parameters (and has same name)
> public static void Foo (BadType t)
> {
> }
> }
>
> Why do not reuse bool Define () methods or DefineContainerMembers method
> where you can simply share a lot of code and don't traverse thought
> whole code tree.
>
>
> I hope, I didn't flood you ;-)
>
> Marek
>
>
>
More information about the Mono-devel-list
mailing list