Use curly quotes where possible in docs (#1737)

We can't use them in stardoc generated docs, as it mangles the encoding
of them...

Author: brentleyjones

README.md

@@ -41,15 +41,15 @@ on it, or [file a new issue][file-an-issue]!
   - [x] Build your Bazel targets with Bazel (a.k.a Build with Bazel or BwB mode)
   - [x] Build your Bazel targets with Xcode, _not_ Bazel
     (a.k.a. Build with Xcode or BwX mode)[^bwx_warning]
-- [x] It "just works"
+- [x] It “just works”
 
 [^bwx_warning]: Build with Bazel mode is the build mode with first class
   support. We will try to make Build with Xcode mode work with every project, but
   there are limitations that can
   [make the experience subpar](/docs/faq.md#why-do-some-of-my-swift_librarys-compile-twice-in-bwx-mode),
   or not work at all. We recommend using BwB mode if possible.
 
-We've also documented the [high-level design goals](/docs/design-goals.md) of
+We’ve also documented the [high-level design goals](/docs/design-goals.md) of
 the ruleset.
 
 ## Projects using rules_xcodeproj
@@ -76,7 +76,7 @@ to include it in the list above.
 | 1.x | 5.3–6.x  | 1.0.1–2.x | 1.x | 13.3–14.x | 12–13.x | `main` |
 
 More versions of these tools and rulesets might be supported, but these are the
-ones we've officially tested with.
+ones we’ve officially tested with.
 
 [1]: https://github.com/bazelbuild/rules_apple
 [2]: https://github.com/bazelbuild/rules_swift

docs/design-goals.md

@@ -8,11 +8,11 @@ rules_xcodeproj has a few high level design goals:
 - The project can be further customized by using additional rules_xcodeproj
   rules, or by returning certain rules_xcodeproj providers from custom rules
 - Outputs are as similar to `bazel build` as possible
-- The project feels as "native" in Xcode as possible
+- The project feels as “native” in Xcode as possible
 - All definition of a project exists in `BUILD` files
 - The project can be configured to use either Xcode or Bazel as the build system
 
-It's also worth mentioning a few non-goals of rules_xcodeproj:
+It’s also worth mentioning a few non-goals of rules_xcodeproj:
 
 - Providing additional non-`xcodeproj` related build rules
 - Changing the way a target builds in order to enable Xcode features
@@ -24,7 +24,7 @@ should build and run. There should be no need to adjust the way your workspace
 is built in any way, or define any additional intermediary targets.
 
 Bazel allows for some pretty complicated stuff, and not all of it will
-automatically translate neatly into Xcode's world. In those cases the project
+automatically translate neatly into Xcode’s world. In those cases the project
 should still build and run (see how in the [build mode](#multiple-build-modes)
 section), but the project might not be in an ideal state (e.g. schemes might not
 be the way you want them, or custom rule targets might not be represented
@@ -33,7 +33,7 @@ ideally). This can be addressed through project customization.
 ## Projects can be customized
 
 As mentioned above, the default state of using just the `xcodeproj` rule might
-result in a project that isn't "ideal". While the project should be able to
+result in a project that isn’t “ideal”. While the project should be able to
 build and run without doing anything else, rules_xcodeproj will support project
 customization through the use of additional rules and providers.
 
@@ -45,8 +45,8 @@ build, and if applicable run, those targets. If possible, all of the transitive
 dependencies will also individually be buildable and runnable. Default schemes
 will be created for each of these Xcode targets.
 
-What if you don't like the way the schemes are created (e.g. too many, with
-incorrect options, or not enough targets per scheme)? Or what if you don't want
+What if you don’t like the way the schemes are created (e.g. too many, with
+incorrect options, or not enough targets per scheme)? Or what if you don’t want
 all of the transitive dependencies represented in Xcode? Or what if you want to
 customize how a target is represented, maybe by adding additional Xcode build
 settings (e.g. to support
@@ -70,13 +70,13 @@ providers that it creates. The rule then uses that information to shape the
 project that it generates.
 
 The `xcodeproj` rule has to make some assumptions about the data it gets, as the
-providers from other rules don't have the fidelity needed to perfectly recreate
+providers from other rules don’t have the fidelity needed to perfectly recreate
 a similar Xcode target. rules_xcodeproj will expose providers and associated
 helper functions, to allow rules, including your own custom ones, to control how
 the `xcodeproj` generates targets. The goal being that a default,
 non-customized, project is as natural as possible. Rules that return
 rules_xcodeproj providers can choose to expose customization points, similar to
-the additional rules mentioned above, but that's not their primary purpose.
+the additional rules mentioned above, but that’s not their primary purpose.
 
 ## Attempts to match the outputs of `bazel build`
 
@@ -87,12 +87,12 @@ care will need to be taken.
 
 ## Native feeling projects
 
-Ideally, you shouldn't be able to tell that a project was generated with
+Ideally, you shouldn’t be able to tell that a project was generated with
 rules_xcodeproj. It should look and feel like any other Xcode project. This
 should also be the case regardless of which [build mode](#multiple-build-modes)
 is used.
 
-When that isn't the case, and there needs to be a deviation (mainly to [satisfy
+When that isn’t the case, and there needs to be a deviation (mainly to [satisfy
 other constraints](#attempts-to-match-the-outputs-of-bazel-build)), then the
 generated project should deviate as little as possible. A [different build
 mode](#build-with-bazel-via-proxy) might be required to make the project feel
@@ -122,15 +122,15 @@ Here are a few reasons one may want to build with
 Xcode instead of Bazel:
 
 - If a new, possibly beta, version of Xcode is released with a feature that
-  Build with Bazel doesn't support yet, because one of Bazel, rules_apple,
-  rules_swift, or rules_xcodeproj doesn't support it
+  Build with Bazel doesn’t support yet, because one of Bazel, rules_apple,
+  rules_swift, or rules_xcodeproj doesn’t support it
 - To work around a bug in Bazel, rules_apple, rules_swift, or rules_xcodeproj
 - To compare the Bazel and Xcode build systems or build commands
 - As a step when migrating to Bazel
 
 ### Build with Xcode
 
-In the "Build with Xcode" mode, the generated project will let Xcode orchestrate
+In the “Build with Xcode” mode, the generated project will let Xcode orchestrate
 the build. Xcode Build Settings, target dependencies, etc. are all set up to
 create a normal Xcode experience.
 
@@ -139,7 +139,7 @@ possible, some things are done differently than a vanilla Xcode project. In
 particular, `BUILT_PRODUCTS_DIR` is set to a nested folder, mirroring the layout
 of `bazel-out/`, and various search paths are adjusted to account for this.
 
-There are also aspects of a Bazel build that can't be neatly translated into an
+There are also aspects of a Bazel build that can’t be neatly translated into an
 Xcode concept (though updating rules to supply [rules_xcodeproj
 providers](#providers) can help). One that will come up in nearly every project
 is code generation. In these situations the project takes on a hybrid approach,
@@ -151,7 +151,7 @@ through the use of [focused project rules](#additional-rules).
 
 ### Build with Bazel
 
-In the "Build with Bazel" mode, the generated project will invoke `bazel build`
+In the “Build with Bazel” mode, the generated project will invoke `bazel build`
 to perform the actual build, as a root or detached dependency, and then stub
 out the build actions that Xcode tries to perform. A version of this method is
 detailed [here](https://github.com/kastiglione/bazel-xcode-demo-swift-driver/tree/master/bazel#disabling-xcodes-build)
@@ -165,25 +165,25 @@ This will be the default build mode by the 1.0 release.
 
 ### Build with Bazel via Proxy
 
-rules_xcodeproj will support one more build mode called "Build with Bazel via
-Proxy". In this mode the generated project will rely on Xcode using an
+rules_xcodeproj will support one more build mode called “Build with Bazel via
+Proxy”. In this mode the generated project will rely on Xcode using an
 [XCBBuildServiceProxy](https://github.com/MobileNativeFoundation/XCBBuildServiceProxyKit).
 This takes the Xcode build system entirely out of the equation, allowing Bazel
 to fully control the build.
 
-Here are some benefits that the proxy provides over "Build with Bazel":
+Here are some benefits that the proxy provides over “Build with Bazel”:
 
-- No additional "BazelDependencies" target in the build graph
+- No additional `BazelDependencies` target in the build graph
 - Removal of duplicate warnings/errors
 - More stable Indexing
 - User created schemes (without defining bazel rules to create them) work as
   expected
 - Fully functional progress bar (though there is hope that we can get it to
-  partially work with "Build with Bazel")
+  partially work with “Build with Bazel”)
 - Less overhead
 
-With all of these benefits, you may be wondering why "Build with Bazel" will be
-the default build mode instead of "Build with Bazel via Proxy". There are two
+With all of these benefits, you may be wondering why “Build with Bazel” will be
+the default build mode instead of “Build with Bazel via Proxy”. There are two
 main reasons:
 
 - The proxy relies on a private API that Xcode uses to communicate with
@@ -199,25 +199,25 @@ main reasons:
   version of Xcode and not work with other versions.
 
 For some teams the benefits outweigh these inconveniences, and there will always
-be the "Build with Bazel" fallback mode in case something goes wrong.
+be the “Build with Bazel” fallback mode in case something goes wrong.
 
 ## No additional non-`xcodeproj` related build rules
 
-rules_xcodeproj won't provide additional non-`xcodeproj` related build rules.
+rules_xcodeproj won’t provide additional non-`xcodeproj` related build rules.
 That is to say, the only rules that will be provided are `xcodeproj` and rules
-that interact directly with `xcodeproj`. These rules won't modify your build
+that interact directly with `xcodeproj`. These rules won’t modify your build
 graph.
 
-To put it yet another way, rules_xcodeproj won't provide rules that make your
-`bazel build` more like Xcode (which is one reason it wasn't named
-"rules_xcode"). Those sorts of rules will have to come from other rulesets.
+To put it yet another way, rules_xcodeproj won’t provide rules that make your
+`bazel build` more like Xcode (which is one reason it wasn’t named
+“rules_xcode”). Those sorts of rules will have to come from other rulesets.
 
-## Won't change the way a target builds in order to enable Xcode features
+## Won’t change the way a target builds in order to enable Xcode features
 
 This non-goal stems from restrictions that SwiftUI previews have, in particular
-that they aren't supported with static libraries. rules_xcodeproj won't change
+that they aren’t supported with static libraries. rules_xcodeproj won’t change
 the product type of your target to enable SwiftUI previews; doing so would get
 in the way of [previous goals](#attempts-to-match-the-outputs-of-bazel-build).
 We will provide guidance on how to change your build yourself and integrate that
-change with rules_xcodeproj, but the rules themselves won't make those changes
+change with rules_xcodeproj, but the rules themselves won’t make those changes
 for you.

docs/faq.md

@@ -9,7 +9,7 @@ referred to as Build with Bazel (BwB) and Build with Xcode (BwX).
 ## Does the Archive action work?
 
 Currently no effort is put into making the Archive action work correctly.
-rules_xcodeproj's primary goal is to support running and debugging of
+rules_xcodeproj’s primary goal is to support running and debugging of
 targets, and might make optimizations that break the generated `.xcarchive` that
 the Archive action produces.
 
@@ -25,7 +25,7 @@ If the transitive closure of dependencies of targets specified by
 will be included in the project with those various configurations. This can be
 useful/expected, for example having multiple platform versions of a given
 `swift_library`. When possible the generated project will have these various
-versions of a target consolidated into a single Xcode target. When targets can't
+versions of a target consolidated into a single Xcode target. When targets can’t
 be consolidated, usually because they are functionally equivalent from the point
 of view of Xcode, they will be separate Xcode targets.
 
@@ -40,16 +40,16 @@ need help, reach out to us.
 
 If you have a top level target, such as `ios_application`, and its primary
 library dependency is also directly depended on by another top level target,
-such as `ios_unit_test`, then we can't merge that library into the first top
-level target. When that happens, the first top level target doesn't have any
+such as `ios_unit_test`, then we can’t merge that library into the first top
+level target. When that happens, the first top level target doesn’t have any
 source files, so we need to add a stub one to allow Xcode to link to the proper
 library target.
 
-If this setup isn't desired (e.g. wanting to have the target merged to enable
+If this setup isn’t desired (e.g. wanting to have the target merged to enable
 SwiftUI Previews), there are a couple ways to fix it. For tests, setting the
 first top level target as the `test_host` will allow for the library to merge.
 In other cases, refactor the build graph to have the shared code in its own
-library separate from the top level target's primary library.
+library separate from the top level target’s primary library.
 
 ## Why do some of my `swift_library`s compile twice in BwX mode?
 
@@ -62,7 +62,7 @@ Possible solutions are:
 
 - Refactoring mixed-language targets to single language targets, removing the
   need for the custom modulemap that references the Swift generated header
-- Remove the use of header maps (hmaps), or don't include Swift generated
+- Remove the use of header maps (hmaps), or don’t include Swift generated
   headers in them
 - Use BwB mode instead
 
@@ -93,16 +93,16 @@ or inline with their `xcodeproj` target. Wrapping the declarations in a function
 is only necessary when sharing a set of custom schemes as is done with the
 fixture tests in this repository.
 
-## Why does "X" happen when switching between build modes?
+## Why does “X” happen when switching between build modes?
 
 The different build modes configure the project in different ways. Because of
 this, if you switch the build mode of a project that has already built
-something, the artifacts in Xcode's Derived Data might cause warnings or errors
-on subsequent builds. rules_xcodeproj thus doesn't officially support this use
+something, the artifacts in Xcode’s Derived Data might cause warnings or errors
+on subsequent builds. rules_xcodeproj thus doesn’t officially support this use
 case, and recommends declaring a different [`xcodeproj`](bazel.md#xcodeproj)
 target for each build mode if needed.
 
-## Why do I get an error like "Provisioning profile "PROFILE_NAME" is Xcode managed, but signing settings require a manually managed profile"?
+## Why do I get an error like “Provisioning profile "PROFILE_NAME" is Xcode managed, but signing settings require a manually managed profile”?
 
 This error should only occur if `build_mode = "xcode"`. If you are using another
 `build_mode`, please report this as a bug.
@@ -132,14 +132,14 @@ Also, the `:provisioning_profile` target needs to be a rule that returns the
 and the `team_id` attribute on that provider needs to be set, or `team_id` needs
 to be set on the `:xcode_profile` target.
 
-## Why do I get an error like "Xcode couldn't find any provisioning profiles matching 'TEAM_ID/PROFILE_NAME'"?
+## Why do I get an error like “Xcode couldn't find any provisioning profiles matching 'TEAM_ID/PROFILE_NAME'”?
 
 This error should only occur if `build_mode = "xcode"`. If you are using another
 `build_mode`, please report this as a bug.
 
 The `provisioning_profile` you have set on your top level target (i.e
 `ios_application` and the like) is resolving to a provisioning profile that
-hasn't yet been installed to `~/Library/MobileDevice/Provisioning Profiles`.
+hasn’t yet been installed to `~/Library/MobileDevice/Provisioning Profiles`.
 This is common if you use the `local_provisioning_profile` rule and specify
 fallback profiles, or if you use specify a profile in the workspace.