Avoid passing context and bundle parameters to directives that don't use them. #1168
Conversation
|
@swift-ci please test |
There was a problem hiding this comment.
Are we able to remove the bundle and context parameter requirement from DirectiveConvertible.init?(from:source:for:in:problems)?
I've had a brief look and it looks like it could be possible, but I'm not sure if there's a layer in which they are required.
Otherwise PR looks good.
| @@ -38,7 +38,7 @@ extension Semantic.Analyses { | |||
| /** | |||
| - returns: All valid headings. | |||
| */ | |||
| @discardableResult public func analyze(_ directive: BlockDirective, children: some Sequence<Markup>, source: URL?, for bundle: DocumentationBundle, in context: DocumentationContext, problems: inout [Problem]) -> [Heading] { | |||
| @discardableResult public func analyze(_ directive: BlockDirective, children: some Sequence<Markup>, source: URL?, for _: DocumentationBundle, in _: DocumentationContext, problems: inout [Problem]) -> [Heading] { | |||
There was a problem hiding this comment.
Can we do the same as with the other Has<Something> analysis types where there's 2 analyze functions, one without the arguments and one with the arguments but deprecated?
There was a problem hiding this comment.
If you're asking about Has[Exactly|AtMost|AtLeast]One, etc. then #1175 makes those changes as well.
I decided to split the work into two PRs because I thought that the second one would be significantly bigger but it turns out it was "only" ~600 LOC changed so perhaps I could have done both in the same PR.
| @available(*, deprecated, message: "This deprecated API will be removed after 6.2 is released") | ||
| extension Semantic.Analyses.ExtractAll: SemanticAnalysis {} | ||
| @available(*, deprecated, message: "This deprecated API will be removed after 6.2 is released") | ||
| extension Semantic.Analyses.ExtractAllMarkup: SemanticAnalysis {} | ||
| @available(*, deprecated, message: "This deprecated API will be removed after 6.2 is released") | ||
| extension Semantic.Analyses.HasAtLeastOne: SemanticAnalysis {} |
There was a problem hiding this comment.
Does this mark the whole type (e.g. Semantic.Analyses.HasAtLeastOne) as deprecated, or does it mark just the functions from the protocol that the conformance is being declared on? Never seen @available used in a protocol extension before :)
There was a problem hiding this comment.
Because I deprecated the protocol, conforming to it would result in a deprecation warning.
Adding @available(*, deprecated, ...) to the extension that specifies the protocol conformance avoids that deprecation warning without deprecating the entire type (like it would if the conformance was declared in the type definition).
I'm tackling that in #1175 which builds on the changes from this PR. There's no directive that uses the |
Bug/issue #, if applicable:
Summary
This avoids passing the
DocumentationContextandDocumentationBundleto directives and semantic analysis that doesn't use it.It also deprecates the
SemanticAnalysisprotocol because it's only conformed to but never used as an existential.Dependencies
None
Testing
Nothing in particular. This isn't a user-facing change.
Checklist
Make sure you check off the following items. If they cannot be completed, provide a reason.
[ ] Added tests./bin/testscript and it succeeded[ ] Updated documentation if necessary