Part 1 of the PackageDescription DocC documentation update #4276

zkiraly · 2022-03-31T00:30:54Z

Part 1: Update DocC documentation in the PackageDescription library. Everything, except Target, Product, and symbols curated under those two.

Motivation:

The DocC documentation in PackageDescription was not complete, and was out of sync with (and in some cases ahead of) Apple's documentation at developer.apple.com.

Modifications:

Many DocC documentation comments were added or changed inside Sources/PackageDescription, except for Target, Product, and symbols curated under those two. The excluded symbols are in a companion PR.

Result:

There was no code change. Only source code comments were changed in Sources/PackageDescription, and DocC extension files were added in the documentation catalog in that directory.

WowbaggersLiquidLunch · 2022-03-31T06:03:35Z

Sources/PackageDescription/LanguageStandardSettings.swift

-    /// ISO C 1990.
+    /// The identifier for the C89 language standard.
    case c89

-    /// ISO C 1990.
+    /// The identifier for the C90 language standard.
    case c90

-    /// ISO C 1999.
+    /// The identifier for the C99 language standard.
    case c99

-    /// ISO C 2011.
+    /// The identifier for the C11 language standard.
    case c11

-    /// ISO C 2017.
+    /// The identifier for the C17 language stadard.
    @available(_PackageDescription, introduced: 5.4)
    case c17

-    /// ISO C 2017.
+    /// The identifier for the C18 language standard.
    @available(_PackageDescription, introduced: 5.4)
    case c18

-    /// Working Draft for ISO C2x.
+    /// The identifier for the C2x draft language standard.
    @available(_PackageDescription, introduced: 5.4)
    case c2x

-    /// ISO C 1990 with GNU extensions.
+    /// The identifier for the GNU89 language standard.
    case gnu89

-    /// ISO C 1990 with GNU extensions.
+    /// The identifier for the GNU90 language standard.
    case gnu90

-    /// ISO C 1999 with GNU extensions.
+    /// The identifier for the GNU99 language standard.
    case gnu99

-    /// ISO C 2011 with GNU extensions.
+    /// The identifier for the GNU11 language standard.
    case gnu11

-    /// ISO C 2017 with GNU extensions.
+    /// The identifier for the GNU17 language standard.
    @available(_PackageDescription, introduced: 5.4)
    case gnu17

-    /// ISO C 2017 with GNU extensions.
+    /// The identifier for the GNU18 language standard.
    @available(_PackageDescription, introduced: 5.4)
    case gnu18

-    /// Working Draft for ISO C2x with GNU extensions.
+    /// The identifier for the GNU2x draft language standard.
    @available(_PackageDescription, introduced: 5.4)
    case gnu2x

-    /// ISO C 1990.
+    /// The identifier for the ISO9899-1990 language standard.
    case iso9899_1990 = "iso9899:1990"

-    /// ISO C 1990 with amendment 1.
+    /// The identifier for the ISO9899-199409 language standard.
    case iso9899_199409 = "iso9899:199409"

-    /// ISO C 1999.
+    /// The identifier for the ISO9899-1999 language standard.
    case iso9899_1999 = "iso9899:1999"

-    /// ISO C 2011.
+    /// The identifier for the ISO9899-2011 language standard.
    case iso9899_2011 = "iso9899:2011"

-    /// ISO C 2017.
+    /// The identifier for the ISO9899-2017 language standard.
    @available(_PackageDescription, introduced: 5.4)
    case iso9899_2017 = "iso9899:2017"

-    /// ISO C 2017.
+    /// The identifier for the ISO9899-2018 language standard.


As pointed out by @abertelrud in #4247, these shouldn't be changed as proposed. The documentation published on apple.com is the outdated one, so it shouldn't be the basis for changing the current documentation.

Agreed. I will use the original designations.

WowbaggersLiquidLunch · 2022-03-31T06:04:54Z

Sources/PackageDescription/LanguageStandardSettings.swift

-    /// ISO C++ 1998 with amendments.
+    /// The identifier for the C++98 language standard.
    case cxx98 = "c++98"

-    /// ISO C++ 1998 with amendments.
+    /// The identifier for the C++03 language standard.
    case cxx03 = "c++03"

-    /// ISO C++ 2011 with amendments.
+    /// The identifier for the C++11 language standard.
    case cxx11 = "c++11"

-    /// ISO C++ 2014 with amendments.
+    /// The identifier for the C++14 language standard.
    case cxx14 = "c++14"

-    /// ISO C++ 2017 with amendments.
+    /// The identifier for the ISO C++ 2017 (with amendments) language standard..
    @available(_PackageDescription, introduced: 5.4)
    case cxx17 = "c++17"

-    /// ISO C++ 2017 with amendments.
+    /// The identifier for the C++1z language standard.
    @available(_PackageDescription, introduced: 4, deprecated: 5.4, renamed: "cxx17")
    case cxx1z = "c++1z"

-    /// ISO C++ 2020 DIS.
+    /// The identifier for the ISO C++ 2020 language standard.
    @available(_PackageDescription, introduced: 5.4)
    case cxx20 = "c++20"

-    /// Working draft for ISO C++ 2023 DIS.
+    /// The identifier for the ISO C++ 2023 draft language standard.
    @available(_PackageDescription, introduced: 5.6)
    case cxx2b = "c++2b"

-    /// ISO C++ 1998 with amendments and GNU extensions.
+    /// The identifier for the GNU++98 language standard.
    case gnucxx98 = "gnu++98"

-    /// ISO C++ 1998 with amendments and GNU extensions.
+    /// The identifier for the GNU++03 language standard.
    case gnucxx03 = "gnu++03"

-    /// ISO C++ 2011 with amendments and GNU extensions.
+    /// The identifier for the GNU++11 language standard.
    case gnucxx11 = "gnu++11"

-    /// ISO C++ 2014 with amendments and GNU extensions.
+    /// The identifier for the GNU++14 language standard.
    case gnucxx14 = "gnu++14"

-    /// ISO C++ 2017 with amendments and GNU extensions.
+    /// The identifier for the GNU++17 language standard.
    @available(_PackageDescription, introduced: 5.4)
    case gnucxx17 = "gnu++17"

-    /// ISO C++ 2017 with amendments and GNU extensions.
+    /// The identifier for the GNU++1z language standard.
    @available(_PackageDescription, introduced: 4, deprecated: 5.4, renamed: "gnucxx17")
    case gnucxx1z = "gnu++1z"

-    /// ISO C++ 2020 DIS with GNU extensions.
+    /// The identifier for the CNU++20 language standard.
    @available(_PackageDescription, introduced: 5.4)
    case gnucxx20 = "gnu++20"

-    /// Working draft for ISO C++ 2023 DIS with GNU extensions.
+    /// The identifier for the GNU++2b draft language standard.


Similarly, these shouldn't be changed as proposed.

I will use the original designations, like so

The identifier for the ISO C++ 2023 draft language standard with GNU extensions.

WowbaggersLiquidLunch · 2022-03-31T06:07:21Z

Sources/PackageDescription/LanguageStandardSettings.swift

+    /// The identifier for the Swift 3 language version.
    @available(_PackageDescription, introduced: 4, obsoleted: 5)
    case v3

+    /// The identifier for the Swift 4 language version.
    @available(_PackageDescription, introduced: 4)
    case v4

+    /// The identifier for the Swift 4.2 language version.
    @available(_PackageDescription, introduced: 4)
    case v4_2

+    /// The identifier for the Swift 5 language version.


In my opinion, it's easier to read if the documentation for each case is just "Swift 3", "Swift 4.2", etc. Most likely, a user reading it already knows that the symbols are identifiers for Swift language versions, so it's probably better to avoid information overload.

We do need a sentence fragment ending in a period, as described in the API Design Guidelines under "Write a Documentation Comment." So I will leave this as is.

WowbaggersLiquidLunch · 2022-03-31T06:14:10Z

Sources/PackageDescription/PackageDependency.swift

        @available(_PackageDescription, introduced: 5.6)
        public enum Kind {
+            /// A dependency based on a file system path.


Maybe "found at" or "located at" is more accurate than "based on"?

Additionally, the convention seems to prefix the word "given" to any parameters mentioned in the summary. For example, in this specific case,

/// A dependency located at the given path. /// - Parameters: /// - name: ... /// - path: ...

The same should apply to the other cases.

I do like "located at." Thanks for the suggestion.

WowbaggersLiquidLunch · 2022-03-31T06:21:50Z

Sources/PackageDescription/PackageDescription.swift

@@ -27,50 +27,60 @@ import Foundation
 /// dependencies, and other configuration options.
 ///
 /// By convention, you need to define the properties of a package in a single
-/// nested initializer statement. Don’t modify it after initialization. The
+/// nested initializer statement. Don't modify it after initialization. The


As mentioned previously, U+2019 is the correct character for punctuation, but U+0027 is more convenient. I don't hold a strong opinion to either one, other than that in general, the choice should be consistent in the entire package.

I had thought I changed all of those, but maybe I missed some, or I somehow reintroduced them? I'll be more vigilant.

Oh, never mind, I misunderstood your comment. Yes, consistency is desired, and I think straight back-ticks are the way to go for this current use case.

WowbaggersLiquidLunch · 2022-03-31T06:29:43Z

Sources/PackageDescription/PackageDescription.docc/PackageDescription.md

+
+The package manifest also allows you to define executable products, as well as plugins that Swift Package Manager can use to build other products in the manifest.
+
+For more information about adding a package dependency to your app project and creating Swift packages with Xcode, see [Adding Package Dependencies to Your App](https://developer.apple.com/documentation/xcode/adding_package_dependencies_to_your_app), [Creating a Standalone Swift Package with Xcode](https://developer.apple.com/documentation/xcode/creating_a_standalone_swift_package_with_xcode/), and [Swift Packages](https://developer.apple.com/documentation/xcode/swift_packages).


I think it's best not to rely on any website or example that's closed-source or not hosted by swift.org, unless there is no other choice. Because their content can change or their links can be dead at any given time, leaving the documentation abruptly outdated. If the linked page is open-source, then the documentation can avoid the problem by linking to a permanent link of a snapshot of it.

This paragraph is about working with Xcode, which I only mention to direct the reader to the correct place where they can read up on using Swift packages with Xcode, which is the Xcode documentation. This documentation is maintained by Apple, and bug reports are appreciated if they do become outdated. Since it's not desired to teach the use of Xcode in the open source documentation, linking to those documents is unavoidable.

WowbaggersLiquidLunch · 2022-03-31T06:32:16Z

Sources/PackageDescription/PackageDescription.swift

+/// The package manifest must begin with the string `// swift-tools-version:`
+/// followed by a version number specifier. The following code listing shows a
+/// few examples of valid declarations of the Swift tools version:
 ///
-/// The Swift tools version declares:
+/// ```swift
+/// // swift-tools-version:3.0.2
+/// // swift-tools-version:3.1
+/// // swift-tools-version:4.0
+/// // swift-tools-version:5.3
+/// ```


As mentioned previously, I think we should add a sentence telling the user that the whitespace rule is relaxed since 5.4, without encouraging any extreme or impractical format. Maybe the tone should be softened a little too, so it doesn't give the user the impression that there is only one accepted format.

Additionally, it might be a good idea to include a few examples for Swift ≥ 5.4, because with the relaxed whitespace parsing rule, new generated tools version specification lines now have a space between ":" and the version specifier for Swift ≥ 5.4.

Thanks for mentioning this again. I will figure something out, and I'd appreciate it if you gave a thumbs up or thumbs down.

WowbaggersLiquidLunch · 2022-03-31T06:36:21Z

Sources/PackageDescription/PackageDescription.swift

-    /// An array of providers for a system target.
+    /// An array of providers for the system target.


I think it's correct to use the indefinite article "a" here, because there isn't a particular system target that is referred to in context.

WowbaggersLiquidLunch · 2022-03-31T06:39:49Z

Sources/PackageDescription/PackageDescription.swift

+    /// - Parameters:
+    ///   - tag: The string representation of an IETF language tag.


I think it's better to use the compact "- Parameter <parameter>: <description>" form to document single-parameter functions.

Same for the few instances below in the same file, and in other files.

I went through, and I think I got all of them.

WowbaggersLiquidLunch · 2022-03-31T06:42:09Z

Sources/PackageDescription/PackageDescription.swift

    public init?(rawValue: String) {
        tag = rawValue
    }
 }

+/// ExpressibleByStringLiteral implementation.


I don't think docc is able to generate documentation for this line. Instead, you can use something like

// MARK: ExpressibleByStringLiteral Conformance

if the intention is to help the reader find this extension quickly.

Let me experiment with this a bit. If DocC does not like it, then it's a bug on DocC, so I am inclined to file a bug and leave this as-is.

WowbaggersLiquidLunch · 2022-03-31T06:45:15Z

Sources/PackageDescription/PackageDescriptionSerialization.swift

+    /// Encodes this value into the given encoder.
+    ///
+    /// If the value fails to encode anything, `encoder` will encode an empty
+    /// keyed container in its place.
+    ///
+    /// This function throws an error if any values are invalid for the given
+    /// encoder's format.
+    ///
+    ///  - Note: This documentation comment was inherited from `Encodable`.
+    ///
+    /// - Parameters:
+    ///   - encoder: The encoder to write data to.


If the documentation is inherited verbatim from the default implementation of encode, then imo it shouldn't be included.

The idea is to have some documentation that makes sense. If the inherited doc does not make sense, that's a problem, and I have written replacement docs in the few cases of protocol conformance docs that I found. Is that the case here too?

Given that this extension is deprecated, and it's an internal implementation detail, I will simplify the documentation for this function.

WowbaggersLiquidLunch · 2022-03-31T06:45:55Z

Sources/PackageDescription/PackageDescriptionSerialization.swift

+    /// Encodes this value into the given encoder.
+    ///
+    /// If the value fails to encode anything, `encoder` will encode an empty
+    /// keyed container in its place.
+    ///
+    /// This function throws an error if any values are invalid for the given
+    /// encoder's format.
+    ///
+    /// - Parameters:
+    ///   - encoder: The encoder to write data to.


I don't think this description is accurate.

I'll talk with Anders more about this. This file is really an internal implementation detail, but Anders thought it was not possible to hide it from DocC. But you are correct, the documentation should be accurate.

WowbaggersLiquidLunch · 2022-03-31T06:46:28Z

Sources/PackageDescription/PackageDescriptionSerialization.swift

+    /// Encodes this value into the given encoder.
+    ///
+    /// If the value fails to encode anything, `encoder` will encode an empty
+    /// keyed container in its place.
+    ///
+    /// This function throws an error if any values are invalid for the given
+    /// encoder's format.
+    ///
+    /// - Parameters:
+    ///   - encoder: The encoder to write data to.


I don't think this description is accurate, either.

Same comment as above about this source file.

WowbaggersLiquidLunch · 2022-03-31T06:48:36Z

Sources/PackageDescription/PackageRequirement.swift

@@ -173,9 +182,13 @@ extension Package.Dependency {
    /// requirements before publishing a version of your package.
    @available(_PackageDescription, introduced: 5.6)
    public enum SourceControlRequirement {
+        /// A version based requirement.


As mentioned in #4247, this is not the only version-based requirement. Maybe we should emphasize the "exactness".

WowbaggersLiquidLunch · 2022-03-31T06:50:57Z

Sources/PackageDescription/SupportedPlatforms.swift

@@ -21,6 +20,11 @@ public struct Platform: Encodable, Equatable {
        self.name = name
    }

+    /// Create a custom platform.


The convention is using 3rd person present tense, so "Creates" instead of "Create".

WowbaggersLiquidLunch · 2022-03-31T06:51:56Z

Sources/PackageDescription/SupportedPlatforms.swift

@@ -21,6 +20,11 @@ public struct Platform: Encodable, Equatable {
        self.name = name
    }

+    /// Create a custom platform.
+    ///
+    /// Use this function if none of the predefined platform names match the platform you are working with.


It might be more accurate to say "targeting" instead of "working with".

WowbaggersLiquidLunch · 2022-03-31T06:53:23Z

Sources/PackageDescription/SupportedPlatforms.swift

    public static func macOS(_ version: SupportedPlatform.MacOSVersion) -> SupportedPlatform {
        return SupportedPlatform(platform: .macOS, version: version.version)
    }

    /// Configures the minimum deployment target version for the macOS platform
    /// using a version string.
    ///
-    /// The version string must be a series of two or three dot-separated integers, such as `10.10` or `10.10.1`.
-    ///
-    /// - Since: First available in PackageDescription 5.0


This line probably shouldn't be deleted.

The same opinion applies to the other deleted "- Since" lines, too.

I put them back in this file. I'll go back and see if there are more in other files.

WowbaggersLiquidLunch · 2022-03-31T06:58:36Z

Sources/PackageDescription/Version.swift

+
+    /// Returns a Boolean value indicating whether two values are equal.
+    ///
+    /// Equality is the inverse of inequality. For any values `a` and `b`, `a ==
+    /// b` implies that `a != b` is `false`.
+    ///
+    /// This is the default implementation of the equal-to operator (`==`) for
+    /// any type that conforms to `Equatable`.
+    ///
+    /// - Parameters:
+    ///   - lhs: A value to compare.
+    ///   - rhs: Another value to compare.


This is not the default implementation of ==.

Removed reference to the default implementation.

WowbaggersLiquidLunch · 2022-03-31T07:02:53Z

Sources/PackageDescription/Version.swift

+    /// The function determines if the inputs have any items in their
+    /// ``Version/prereleaseIdentifiers`` collections.
+    /// If only one side has prerelease identifiers, then that side will be considered
+    /// to have the lower version number. If they both have prerelease identifiers,
+    /// then the numeric prerelease identifier is considered to be lower version.
+    /// If both prerelease identifiers are numeric, then a numeric comparison is made.
+    ///
+    /// If neither of the parameters have prerelease identifiers, then the <doc://com.apple.documentation/documentation/swift/array/2853083-lexicographicallyprecedes>
+    /// function is used to perform the comparison.


This description is incorrect. Additionally, it's exposing the implementation detail to the public documentation. I think it's probably better to paraphrase the precedence rules listed on semver.org instead.

It might be best if I just wrote

The precedence is determined according to rules described at the Semantic Versioning 2.0.0 website.

And leave it at that. I provide the exact link to the precedence rules, and the description there is easy to follow.

…nts.

zkiraly · 2022-04-20T23:20:17Z

@swift-ci please smoke test.

WowbaggersLiquidLunch · 2022-04-21T22:07:16Z

Sources/PackageDescription/PackageDescription.docc/Curation/Extensions/LanguageTag-notEqual.md

+
+Inequality is the inverse of equality. For any values a and b, a != b implies that a == b is false.
+
+This is the default implementation of the not-equal-to operator (!=) for any type that conforms to Equatable.


Related to a comment i left before: I don't think it adds value to copy-paste the default implementation's documentation. If there is anything unique, then we should customize the documentation. If there is nothing to customize, then we should just let the documentation automatically be inherited from the default implementation's; otherwise, the copy-pasted documentation can become silently outdated when the default implementation's changes.

The same opinion applies to the other PR too.

WowbaggersLiquidLunch · 2022-04-21T22:11:41Z

Sources/PackageDescription/SupportedPlatforms.swift

-
-    /// Configures the minimum deployment target version for the watchOS platform
-    /// using a custom version string.
+


whitespace-only line

Ok, it took me a while to get it. Yes, I see the problem. Thank you.

zkiraly · 2022-04-22T17:38:49Z

@swift-ci please smoke test.

abertelrud · 2022-04-22T18:07:09Z

Sources/PackageDescription/LanguageStandardSettings.swift

-/// To learn more, read the [Clang Compiler User's Manual][1].
-///
-/// [1]: <https://clang.llvm.org/docs/UsersManual.html#differences-between-various-standard-modes>
+/// The supported C language standard you use to complile C sources in the


Suggested change

/// The supported C language standard you use to complile C sources in the

/// The supported C language standard you use to compile C sources in the

abertelrud · 2022-04-22T18:09:47Z

Sources/PackageDescription/LanguageStandardSettings.swift

    @available(_PackageDescription, introduced: 5.4)
    case iso9899_2018 = "iso9899:2018"
 }

-/// The supported C++ language standard to use for compiling C++ sources in the package.
+/// The supported C++ language standard tyou use to compile C++ sources in the


Suggested change

/// The supported C++ language standard tyou use to compile C++ sources in the

/// The supported C++ language standard you use to compile C++ sources in the

abertelrud · 2022-04-22T18:12:14Z

Sources/PackageDescription/PackageDependency.swift

+            ///  - Parameters:
+            ///    - name: The name of the dependency.
+            ///    - location: The Git URL of the dependency.
+            ///    - requirement: A `SourceControlRequirement` instance.


Should this also be The version based requirement for a package like the case below? It's exactly the same use, and when seen in the code completion or help in Xcode, it's already apparent that the type is SourceControlRequirement.

abertelrud · 2022-04-22T18:14:58Z

Sources/PackageDescription/PackageDependency.swift

+            ///  - Parameters:
+            ///    - name: The name of the dependency.
+            ///    - location: The Git URL of the dependency.
+            ///    - requirement: A `SourceControlRequirement` instance.


Suggested change

/// - requirement: A `SourceControlRequirement` instance.

/// - requirement: The version based requirement for a package.

abertelrud · 2022-04-22T18:22:19Z

Sources/PackageDescription/PackageDescription.swift

    public var name: String

-    /// The list of supported platforms with a custom deployment target.
+    /// The list of platforms supported by the package.


This isn't exactly what this property represents, unfortunately ("unfortunately" because the name suggests that it is). What this does is specify the minimum version required for each of the platforms, e.g. macOS 10.15 for macOS, etc. So I suggest "The list of minimum versions for platforms supported by the package".

abertelrud · 2022-04-22T18:22:53Z

Sources/PackageDescription/PackageDescription.swift

    public var name: String

-    /// The list of supported platforms with a custom deployment target.
+    /// The list of platforms supported by the package.


Suggested change

/// The list of platforms supported by the package.

/// The list of minimum versions for platforms supported by the package.

abertelrud · 2022-04-22T18:28:27Z

Looks good, thank you for doing this work! A couple of spelling mistakes and a suggestion for an improved description. The only significant one is that platforms is more about the minimum deployment targets than actually restricting supported platforms — this is a point of confusion in the API itself. I have suggested replacement wording.

zkiraly · 2022-04-22T19:15:32Z

@swift-ci please smoke test.

zkiraly · 2022-04-22T19:44:45Z

@swift-ci please smoke test.

zkiraly · 2022-04-22T21:32:23Z

@swift-ci please smoke test.

zkiraly · 2022-04-22T21:42:25Z

@swift-ci please smoke test.

* Part 2 of the documentation update. * Adopted some of the comments from the companion PR #4276. * A few minor edits to the DocC documentation comments. * More minor edits. * Another minor edit. * Removed some unwanted blank-space. * Changed "apply" to 3rd person present tense. * Removed blank-space. * Fixed a typo/ * Added back the Since docs that were deleted. Co-authored-by: Zsolt Kiraly <[email protected]>

…#4277) * Part 2 of the documentation update. * Adopted some of the comments from the companion PR swiftlang#4276. * A few minor edits to the DocC documentation comments. * More minor edits. * Another minor edit. * Removed some unwanted blank-space. * Changed "apply" to 3rd person present tense. * Removed blank-space. * Fixed a typo/ * Added back the Since docs that were deleted. Co-authored-by: Zsolt Kiraly <[email protected]>

* Part 2 of the documentation update. * Adopted some of the comments from the companion PR #4276. * A few minor edits to the DocC documentation comments. * More minor edits. * Another minor edit. * Removed some unwanted blank-space. * Changed "apply" to 3rd person present tense. * Removed blank-space. * Fixed a typo/ * Added back the Since docs that were deleted. Co-authored-by: Zsolt Kiraly <[email protected]>

Part 1 of the documentation update.

59b63a5

zkiraly mentioned this pull request Mar 31, 2022

[Do Not Merge] Update DocC documentation in the PackageDescription library. #4247

Closed

WowbaggersLiquidLunch reviewed Mar 31, 2022

View reviewed changes

abertelrud mentioned this pull request Apr 5, 2022

Restore the doc of package(name:exact:) #4269

Merged

Zsolt Kiraly and others added 6 commits April 6, 2022 20:25

Corrected the docs for two Package.Dependency methods.

4262d29

Changed the docs for the C language standards in response to PR comme…

81ccd41

…nts.

Updated all the language standard identifier docs.

4c2f9ce

More responses to comments on the PR.

b0a7cca

Responded to more comments.

7421574

Merge branch 'main' into zkiraly/documentation-update-1

b84390f

zkiraly pushed a commit to zkiraly/swift-package-manager that referenced this pull request Apr 8, 2022

Adopted some of the comments from the companion PR swiftlang#4276.

2a74e86

Some light editing of the DocC documentation.

846916b

zkiraly requested review from neonichu, tomerd and elsh as code owners April 20, 2022 23:19

neonichu approved these changes Apr 21, 2022

View reviewed changes

WowbaggersLiquidLunch reviewed Apr 21, 2022

View reviewed changes

Removed unwanted blank-space.

b6fc718

abertelrud reviewed Apr 22, 2022

View reviewed changes

Responding to Anders' notes.

105ba7f

Merge branch 'apple:main' into zkiraly/documentation-update-1

44ba513

Zsolt Kiraly added 2 commits April 22, 2022 14:29

I should not have touched this file, so I am reverting my changes there.

5feb566

We can't link below the top level for legal reasons.

f2958b9

A small editorial change.

2b50fb8

zkiraly merged commit 911556a into swiftlang:main Apr 23, 2022

zkiraly mentioned this pull request Apr 23, 2022

[5.7] Cherry-pick DocC documentation updates. #4319

Merged


		The package manifest also allows you to define executable products, as well as plugins that Swift Package Manager can use to build other products in the manifest.

		For more information about adding a package dependency to your app project and creating Swift packages with Xcode, see [Adding Package Dependencies to Your App](https://developer.apple.com/documentation/xcode/adding_package_dependencies_to_your_app), [Creating a Standalone Swift Package with Xcode](https://developer.apple.com/documentation/xcode/creating_a_standalone_swift_package_with_xcode/), and [Swift Packages](https://developer.apple.com/documentation/xcode/swift_packages).

		/// An array of providers for a system target.
		/// An array of providers for the system target.

		/// - Parameters:
		/// - tag: The string representation of an IETF language tag.


		Inequality is the inverse of equality. For any values a and b, a != b implies that a == b is false.

		This is the default implementation of the not-equal-to operator (!=) for any type that conforms to Equatable.


		/// Configures the minimum deployment target version for the watchOS platform
		/// using a custom version string.

	/// The supported C language standard you use to complile C sources in the
	/// The supported C language standard you use to compile C sources in the

	/// The supported C++ language standard tyou use to compile C++ sources in the
	/// The supported C++ language standard you use to compile C++ sources in the

	/// - requirement: A `SourceControlRequirement` instance.
	/// - requirement: The version based requirement for a package.

	/// The list of platforms supported by the package.
	/// The list of minimum versions for platforms supported by the package.

Part 1 of the PackageDescription DocC documentation update #4276

Part 1 of the PackageDescription DocC documentation update #4276

Uh oh!

Conversation

zkiraly commented Mar 31, 2022

Motivation:

Modifications:

Result:

Uh oh!

WowbaggersLiquidLunch Mar 31, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zkiraly Apr 7, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

WowbaggersLiquidLunch Mar 31, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

WowbaggersLiquidLunch Mar 31, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

WowbaggersLiquidLunch Mar 31, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

WowbaggersLiquidLunch Mar 31, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

WowbaggersLiquidLunch Mar 31, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

WowbaggersLiquidLunch Mar 31, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

WowbaggersLiquidLunch Mar 31, 2022 •

edited

Loading

zkiraly Apr 7, 2022 •

edited

Loading

WowbaggersLiquidLunch Mar 31, 2022 •

edited

Loading

WowbaggersLiquidLunch Mar 31, 2022 •

edited

Loading

WowbaggersLiquidLunch Mar 31, 2022 •

edited

Loading

WowbaggersLiquidLunch Mar 31, 2022 •

edited

Loading

WowbaggersLiquidLunch Mar 31, 2022 •

edited

Loading

WowbaggersLiquidLunch Mar 31, 2022 •

edited

Loading

WowbaggersLiquidLunch Mar 31, 2022 •

edited

Loading

WowbaggersLiquidLunch Apr 21, 2022 •

edited

Loading

zkiraly Apr 21, 2022 •

edited

Loading