Support context parameters in @param tag
#4398
Conversation
vmishenev
left a comment
There was a problem hiding this comment.
Another way around this is to basically have the logic from KdocMarkdowsParser implemented in the DescriptorSections. I think it makes sense to have this logic on the "documentable model" side
As for me, the current approach is okay. In DescriptorSections, we would need to calculate what a parameter is.
| |/src/main/kotlin/test/source.kt | ||
| |package test | ||
| | /** | ||
| | * @param[this] receiver |
There was a problem hiding this comment.
Should @param[this] be allowed?
The KEEP: Streamline ambiguous KDoc links explicitly prohibit this case.
There was a problem hiding this comment.
I don't think we explicitly agreed on this. It was discussed in #4065, I implemented it here as a 'test' to get feedback on do we really want this behaviour
| customTagSectionContent(d, sourceSets, customTagContentProviders) | ||
| unnamedTagSectionContent(d, sourceSets) { toHeaderString() } | ||
|
|
||
| contextParamsSectionContent(tags) |
There was a problem hiding this comment.
Have we decided to have a separate section? Should QDoc do the same?
There was a problem hiding this comment.
In this case, should we separate the parameters of a function/constructor from the type parameters as well?
There was a problem hiding this comment.
That makes sense, we can do that too. @whyoleg wdyt?
Basic implementation of #4065.
Adding a new
TagWrapperis also an API breaking change. Another way around this is to basically have the logic fromKdocMarkdowsParserimplemented in theDescriptorSections. I think it makes sense to have this logic on the "documentable model" side, but I don't have a strong opinion here.If we want to go with this implementation, probably we also need to update IDE to have similar behaviour.