[IDE][SourceKit/DocSupport] Add members of underscored protocol extensions in extensions of conforming types. #32148
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@swift-ci please test |
…sions in extensions of conforming types. We would previously hide the protocol, its extensions and members, but the '_' prefix really just means the protocol itself isn't intended for clients, rather than its members. This also adds support for 'fully_annotated_decl' entries in doc-info for extensions to be consistent with every other decl, and removes the 'fully_annotated_generic_signature' entry we supplied as a fallback. Also fixes several bugs with the synthesized extensions mechanism: - The type sustitutions applied to the extension's requirements were computed using the extension itself as the decl context rather than the extension's nominal. The meant the extension's requirements themselves were assumed to hold when determining the substitutions, so equality constraints were always met. Because of this extension members were incorrectly merged with the base nominal or its extensions despite having additional constraints. - Types within the requirements weren't being transformed when printed (e.g. 'Self.Element' was printed rather than 'T') both in the interface output and in the requirements list. We were also incorrectly printing requirements that were already satisfied once the base type was subsituted in. - If both the protocol extension and 'enabling' extension of the base nominal that added the protocol conformance had conditional requirements, we were only printing the protocol extension's requirements in the synthesized extension. - The USR and annotated decl output embedded in the 'key.doc.full_as_xml' string for synthesized members were printed to match their original context, rather than the synthesized one. Resolves rdar://problem/57121937
nathawes
force-pushed
the
doc-info-underscored-protocol-synthesised-extensions
branch
from
b19681a to
51bace6
Compare
|
@swift-ci please test |
|
Build failed |
|
@swift-ci please test OS X Platform |
akyrtzi
approved these changes
Jun 10, 2020
nathawes
deleted the
doc-info-underscored-protocol-synthesised-extensions
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We would previously hide underscored protocols and their extensions and members, but the
_prefix really just means the protocols themselves aren't intended for clients, rather than their members.This also adds support for
fully_annotated_declentries for extensions in doc-info in order to be consistent with every other decl, and removes the 'fully_annotated_generic_signature' entry we supplied as a fallback.Also fixes several bugs with the synthesized extensions mechanism:
Self.Elementwas printed rather thanT) both in the interface output and in the requirements list. We were also incorrectly printing requirements that were already satisfied once the base type was substituted in.key.doc.full_as_xmlstring for synthesized members were printed to match their original context, rather than the synthesized one.Resolves rdar://problem/57121937