You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fixes rdar://109417745.
* Add `@AlternateRepresentation` directive
Adds a new child directive to `@Metadata` which can be used in a symbol extension file by specifying the link to another symbol:
```swift
@metadata {
@AlternateRepresentation(``MyClass/property``)
}
```
External links are also supported, as long as they're quoted:
```swift
@metadata {
@AlternateRepresentation("doc://com.example/documentation/MyClass/property")
}
```
The intent of this directive is to define an alternate language representation for the current symbol, such that both symbols are considered to be alternate representations of the same symbol.
Ideally two symbols which are equivalent would have the same USR and be resolved as the same symbol by the compiler, but this is not always the case. For the cases in which it is not feasible to change the source code to have them as one symbol, the `@AlternateRepresentation` directive can be used to manually link them as variants of each other.
Discussion:
----------
A mutable topic reference type was chosen as the type for parsing&storing the link
so that it can be parsed as an unresolved link at the directive parsing stage,
and then later be updated to a resolved link at a later stage when the documentation context is resolving all links.
A parsing failure diagnostic is returned if the link is invalid in any way:
```
AlternateRepresentation expects an argument for an unnamed parameter that's convertible to 'TopicReference'
--> SynonymSample.docc/Symbol.md:4:31-4:37
2 |
3 | @metadata {
4 + @AlternateRepresentation("doc://")
5 | }
6 |
```
This commit adds the directive itself, but doesn't hook it up to other parts of SwiftDocC. Subsequent commits will add:
- link resolution
- rendering logic
Alternatives considered:
-----------------------
Considered other names such as `@Synonym`, `@Counterpart`, `@AlternativeDeclaration` and `@VariantOf`.
In the end disqualified these as being confusing, and chose `@AlternateRepresentation` for being the one which strikes the best balance between readable and closeness to the technical term for this concept.
* Resolve topic references in `@AlternateRepresentation`
Adds logic in `DocumentationContext` which will resolve the references inside the alternate representation directive.
The same logic is used as for resolving all other links.
This is done outside the usual ReferenceResolver visit of the semantic object, because `Symbol` objects don't have access to the node metadata, where the unresolved link resides.
If the link cannot be resolved, the usual diagnostic is emitted:
```
warning: 'MissingSymbol' doesn't exist at '/Synonyms'
--> SynonymSample.docc/SymbolExtension2.md:4:19-4:32
2 |
3 | @metadata {
4 + @AlternateRepresentation(``Synonyms/MissingSymbol``)
5 | }
```
* Diagnose duplicate representations of `@AlternateRepresentation`
If an `@AlternateRepresentation` clashes with already available source languages, this will now be reported as diagnostics.
These diagnostics are performed in the final stage of registering a bundle, during the global analysis of the topic graph, where all nodes are available and all links will have been resolved. This is so that we have all the information we need for detecting duplicates.
The following cases are detected:
- if the symbol the alternate representation is being defined for (the "original" symbol) was already available in one of the languages the counterpart symbol is available in
- if the alternate representations have duplicate source languages in common, i.e. if counterpart1 is available in Objective-C and counterpart2 is **also** available in Objective-C.
Suggestions will be provided depending on context:
- which languages are duplicate
- all the languages the symbol is already available in will be available as part of the diagnostic explanation
- if the `@AlternateRepresentation` directive is a duplicate, a suggestion will be made to remove it, with a suitable replacement
- if the `@AlternateRepresentation` directive is a duplicate, a note pointing to the original directive will be added
Example diagnostics:
```
warning: An alternate representation for Swift already exists
This node is already available in Swift and Objective-C.
SynonymSample.docc/SymbolExtension2.md:4:5: An alternate representation for Swift has already been defined by an @AlternateRepresentation directive.
--> SynonymSample.docc/SymbolExtension2.md:5:5-5:57
3 | @metadata {
4 | @AlternateRepresentation(``Synonyms/Synonym-5zxmc``)
5 + @AlternateRepresentation(``Synonyms/Synonym-5zxmc``)
| ╰─suggestion: Remove this alternate representation
6 | }
7 |
```
```
warning: This node already has a representation in Swift
This node is already available in Swift.
--> SynonymSample.docc/SynonymExtension.md:5:5-5:56
3 | @metadata {
4 | @AlternateRepresentation(``Synonyms/Synonym-1wqxt``)
5 + @AlternateRepresentation(``Synonyms/OtherSynonym``)
| ╰─suggestion: Replace the counterpart link with a node which isn't available in Swift
6 | }
7 |
```
* Emit diagnostics for non-symbol pages
The `@AlternateRepresentation` directive is not expected for non-symbol pages, and we now emit diagnostics for this case.
For example, if an `@AlternateDeclaration` directive is added to an article, the resulting diagnostic will be:
```
warning: Custom alternate representations are not supported for page kind 'Article'
Alternate representations are only supported for symbols.
--> ./SynonymSample.docc/Article.md:4:5-4:57
2 |
3 | @metadata {
4 + @AlternateRepresentation(``Synonyms/Synonym-5zxmc``)
| ╰─suggestion: Remove this alternate representation
5 | }
```
And if a custom alternate declaration to an article is specified, the resulting dia
gnostic will be:
```
warning: Page kind 'Article' is not allowed as a custom alternate language representation
Symbols can only specify other symbols as custom language representations.
--> ./SynonymSample.docc/Synonym-1wqxt.md:5:5-5:44
3 | @metadata {
4 | @AlternateRepresentation(``Synonyms/Synonym-5zxmc``)
5 + @AlternateRepresentation("doc:Article")
| ╰─suggestion: Remove this alternate representation
6 | }
```
* Render alternate representations as node variants
When rendering the variants of a node, use the topic references from the `@AlternateRepresentation` directives to populate more variants.
There is no need to report diagnostics as they would have been reported during bundle registration.
Link resolution would have already been performed at that point.
Unresolved topic references are ignored, but all resolved references are added as variants.
If there are multiple symbols per variant, Swift-DocC-Render prefers the first one that was added, which will always be the current node's symbol.
There should be no breakage and change of behaviour for anyone not using `@AlternateRepresentation`, and the current symbol's variants will always be preferred over any other.
* Add `AlternateRepresentation` to Metadata article (#1128)
The metadata article curates a list of its child directives, with relevant topic titles.
This adds `AlternateRepresentation` to that list, in the same section as `SupportedLanguage` as they both deal with language representations.
summary:"\(entity.name.plainText.singleQuoted) already has a representation in \(listSourceLanguages(duplicateSourceLanguages))",
3277
+
explanation:"Symbols can only specify custom alternate language representations for languages that the documented symbol doesn't already have a representation for."
3278
+
),
3279
+
possibleSolutions:[Solution(summary:"Replace this alternate language representation with a symbol which isn't available in \(listSourceLanguages(entity.availableSourceLanguages))", replacements:[])]
// Only alternate representations which were able to be resolved to a reference should be included as an alternate representation.
1863
+
// Unresolved alternate representations can be ignored, as they would have been reported during link resolution.
1864
+
guard case .resolved(.success(let alternateRepresentationReference))= alternateRepresentation.reference else{
1865
+
continue
1866
+
}
1867
+
1868
+
// Add the language representations of the alternate symbol as additional variants for the current symbol.
1869
+
// Symbols can only specify custom alternate language representations for languages that the documented symbol doesn't already have a representation for.
1870
+
// If the current symbol and its custom alternate representation share language representations, the custom language representation is ignored.
This source file is part of the Swift.org open source project
3
+
4
+
Copyright (c) 2024 Apple Inc. and the Swift project authors
5
+
Licensed under Apache License v2.0 with Runtime Library Exception
6
+
7
+
See https://swift.org/LICENSE.txt for license information
8
+
See https://swift.org/CONTRIBUTORS.txt for Swift project authors
9
+
*/
10
+
11
+
import Foundation
12
+
import Markdown
13
+
14
+
15
+
/// A directive that configures an alternate language representation of a symbol.
16
+
///
17
+
/// An API that can be called from more than one source language has more than one language representation.
18
+
///
19
+
/// Whenever possible, prefer to define alternative language representations for a symbol by using in-source annotations
20
+
/// such as the `@objc` and `@_objcImplementation` attributes in Swift,
21
+
/// or the `NS_SWIFT_NAME` macro in Objective C.
22
+
///
23
+
/// If your source language doesn’t have a mechanism for specifying alternate representations or if your intended alternate representation isn't compatible with those attributes,
24
+
/// you can use the `@AlternateRepresentation` directive to specify another symbol that should be considered an alternate representation of the documented symbol.
/// If you prefer, you can wrap the symbol link in a set of double backticks (\`\`), or use any other supported syntax for linking to symbols.
32
+
/// For more information about linking to symbols, see <doc:linking-to-symbols-and-other-content>.
33
+
///
34
+
/// This provides a hint to the renderer as to the alternate language representations for the current symbol.
35
+
/// The renderer may use this hint to provide a link to these alternate symbols.
36
+
/// For example, Swift-DocC-Render shows a toggle between supported languages, where switching to a different language representation will redirect to the documentation for the configured alternate symbol.
37
+
///
38
+
/// ### Special considerations
39
+
///
40
+
/// Links containing a colon (`:`) must be wrapped in quotes:
/// The `@AlternateRepresentation` directive only specifies an alternate language representation in one direction.
49
+
/// To define a two-way relationship, add an `@AlternateRepresentation` directive, linking to this symbol, to the other symbol as well.
50
+
///
51
+
/// You can only configure custom alternate language representations for languages that the documented symbol doesn't already have a language representation for,
52
+
/// either from in-source annotations or from a previous `@AlternateRepresentation` directive.
0 commit comments