Problem
In the template model being ported in #84, documentation is a bag of raw strings:
publicList<string>Comments{get;set;}=[];Callers therefore hand-assemble XML doc comments line by line, including the /// prefix and the tag markup. ktsu.Semantics even keeps named constants for the delimiters to avoid typos:
internalconststringSummaryOpen="/// <summary>";internalconststringSummaryClose="/// </summary>";
Three consequences:
- Nothing escapes the content. A description containing
<, > or & — entirely plausible for a type described in metadata, e.g. "values in the range <0, 1>" — emits malformed XML and trips the compiler's doc-comment warnings. - Nothing enforces structure. A
<param> tag whose name does not match any parameter produces CS1572/CS1573 in the generated file, and there is no way for the model to catch it even though it knows the parameter list. - Every generator re-derives the same layout — which tags in which order, how to wrap long lines, how to indent a multi-line
<remarks>.
Proposal
Add a DocComment type carrying the standard tags, and render it from the template:
publicsealedclassDocComment{publicstring?Summary{get;set;}publicstring?Remarks{get;set;}publicstring?Returns{get;set;}publicstring?Value{get;set;}publicList<(stringName,stringText)>Params{get;}publicList<(stringName,stringText)>TypeParams{get;}publicList<(stringCref,stringText)>Exceptions{get;}publicList<string>SeeAlso{get;}publicstring?InheritDoc{get;set;}// renders /// <inheritdoc/>}with:
- XML-escaping of all text content by default, and an explicit opt-out for callers who are deliberately embedding markup such as
<c> or <see cref="..."/>; - canonical tag order (
summary, typeparam, param, returns, value, exception, remarks, seealso); - correct
/// prefixing and indentation for multi-line text, honouring the configured indent string; - optional validation against the owning template's parameter and type-parameter lists, surfaced as an exception or a diagnostic rather than as a compile error in the generated output.
Keep Comments as the escape hatch for non-doc comments and anything the model does not cover.
Acceptance criteria
Context
Part of ktsu-dev/Semantics#181. Depends on #84.
Problem
In the template model being ported in #84, documentation is a bag of raw strings:
Callers therefore hand-assemble XML doc comments line by line, including the
///prefix and the tag markup.ktsu.Semanticseven keeps named constants for the delimiters to avoid typos:Three consequences:
<,>or&— entirely plausible for a type described in metadata, e.g. "values in the range<0, 1>" — emits malformed XML and trips the compiler's doc-comment warnings.<param>tag whose name does not match any parameter produces CS1572/CS1573 in the generated file, and there is no way for the model to catch it even though it knows the parameter list.<remarks>.Proposal
Add a
DocCommenttype carrying the standard tags, and render it from the template:with:
<c>or<see cref="..."/>;summary,typeparam,param,returns,value,exception,remarks,seealso);///prefixing and indentation for multi-line text, honouring the configured indent string;Keep
Commentsas the escape hatch for non-doc comments and anything the model does not cover.Acceptance criteria
DocCommentrenders each supported tag in canonical order with correct prefixing and indentation.<param>/<typeparam>names can be validated against aMethodTemplate/ConstructorTemplateparameter list.<remarks>and<summary>render each line with its own///prefix.README.mddocuments the type with an example.Context
Part of ktsu-dev/Semantics#181. Depends on #84.