Replace curled quotes with ASCII quotes.
Replace ? and ? with ", replace ? and ? with '.
These are fine in text, but not in BUILD file
examples, because if the user copy-pastes the
BUILD file then Bazel won't understand these
quotes.
PiperOrigin-RevId: 256667018
diff --git a/scripts/ci/ci.sh b/scripts/ci/ci.sh
index 67f47d3..ce84024 100755
--- a/scripts/ci/ci.sh
+++ b/scripts/ci/ci.sh
@@ -27,7 +27,7 @@
# infrastructure.
# https://mike-bland.com/2012/10/01/tools.html#tools-tap-sponge
#
-# "Every single change submitted to Google’s Perforce depot is built and
+# "Every single change submitted to Google's Perforce depot is built and
# tested, and only those targets affected by a particular change are
# built and tested"
#
diff --git a/site/docs/bazel-vision.md b/site/docs/bazel-vision.md
index 3d93891..d0aad8a 100644
--- a/site/docs/bazel-vision.md
+++ b/site/docs/bazel-vision.md
@@ -17,7 +17,7 @@
to reinvent the basic plumbing.
* **Engineers can easily contribute to any project.** A developer who wants to
start working on a new project can simply clone the project and run the
- build. There’s no need for local configuration - it just works. With
+ build. There's no need for local configuration - it just works. With
cross-platform remote execution, they can work on any machine anywhere and
fully test their changes against all platforms the project targets.
Engineers can quickly configure the build for a new project or incrementally
@@ -36,7 +36,7 @@
corruption) and distributability (build actions are isolated and can be
offloaded). By minimizing the work needed to do a correct build and
parallelizing that work across multiple cores and remote systems, Bazel can make
-any build fast. Bazel’s abstraction layer—instructions specific to languages,
+any build fast. Bazel's abstraction layer—instructions specific to languages,
platforms, and toolchains implemented in a simple extensibility language —
allows it to be easily applied to any context.
diff --git a/site/docs/migrate-maven.md b/site/docs/migrate-maven.md
index ff36fe7..cdf9cd3 100644
--- a/site/docs/migrate-maven.md
+++ b/site/docs/migrate-maven.md
@@ -5,7 +5,7 @@
# Migrating from Maven to Bazel
-When migrating from any build tool to Bazel, it’s best to have both build
+When migrating from any build tool to Bazel, it's best to have both build
tools running in parallel until you have fully migrated your development team,
CI system, and any other relevant systems. You can run Maven and Bazel in the
same repository.
@@ -25,10 +25,10 @@
## Before you begin
-* [Install Bazel](install.md) if it’s not yet installed.
-* If you’re new to Bazel, go through the tutorial
+* [Install Bazel](install.md) if it's not yet installed.
+* If you're new to Bazel, go through the tutorial
[Introduction to Bazel: Build Java](tutorial/java.md) before you start
- migrating. The tutorial explains Bazel’s concepts, structure, and label
+ migrating. The tutorial explains Bazel's concepts, structure, and label
syntax.
## Differences between Maven and Bazel
@@ -63,7 +63,7 @@
has no external dependencies, the workspace file can be empty.
If your project depends on files or packages that are not in one of the
-project’s directories, specify these external dependencies in the workspace
+project's directories, specify these external dependencies in the workspace
file. To automate the listing of external dependencies for the workspace file,
use `rules_jvm_external`. For instructions about using this ruleset, see
[the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external).
@@ -170,7 +170,7 @@
```
* Specify the attributes:
* `name`: Give the target a meaningful name. In the examples above
- we call the target “everything.”
+ we call the target "everything."
* `srcs`: Use globbing to list all .java files in your project.
* `resources`: Use globbing to list all resources in your project.
* `deps`: You need to determine which external dependencies your
@@ -242,7 +242,7 @@
### <a name="4-build"></a>4. Build using Bazel
-You’ve been building using Bazel as you add BUILD files to validate the setup
+You've been building using Bazel as you add BUILD files to validate the setup
of the build.
When you have BUILD files at the desired granularity, you can use Bazel
diff --git a/site/docs/remote-caching.md b/site/docs/remote-caching.md
index 2a64a9a..a2c9abb 100644
--- a/site/docs/remote-caching.md
+++ b/site/docs/remote-caching.md
@@ -14,7 +14,7 @@
* [Remote caching overview](#remote-caching-overview)
* [How a build uses remote caching](#how-a-build-uses-remote-caching)
-* [Setting up a server as the cache’s backend](#setting-up-a-server-as-the-caches-backend)
+* [Setting up a server as the cache's backend](#setting-up-a-server-as-the-caches-backend)
* [nginx](#nginx)
* [Bazel Remote Cache](#bazel-remote-cache)
* [Google Cloud Storage](#google-cloud-storage)
@@ -39,11 +39,11 @@
You can set up a server to be a remote cache for build outputs, which are these
action outputs. These outputs consist of a list of output file names and the
hashes of their contents. With a remote cache, you can reuse build outputs
-from another user’s build rather than building each new output locally.
+from another user's build rather than building each new output locally.
To use remote caching:
-* Set up a server as the cache’s backend
+* Set up a server as the cache's backend
* Configure the Bazel build to use the remote cache
* Use Bazel version 0.10.0 or later
@@ -227,12 +227,12 @@
You may also need configure authentication, which is specific to your
chosen server.
-You may want to add these flags in a `.bazelrc` file so that you don’t
+You may want to add these flags in a `.bazelrc` file so that you don't
need to specify them every time you run Bazel. Depending on your project and
team dynamics, you can add flags to a `.bazelrc` file that is:
* On your local machine
-* In your project’s workspace, shared with the team
+* In your project's workspace, shared with the team
* On the CI system
### Read from and write to the remote cache
@@ -297,7 +297,7 @@
or delete old outputs.
The cached outputs are stored as a set of names and hashes. When deleting
-content, there’s no way to distinguish which output belongs to a specific
+content, there's no way to distinguish which output belongs to a specific
build.
You may want to delete content from the cache to:
diff --git a/site/docs/rule-challenges.md b/site/docs/rule-challenges.md
index 1d39695..5f7edfd 100644
--- a/site/docs/rule-challenges.md
+++ b/site/docs/rule-challenges.md
@@ -7,7 +7,7 @@
We have heard feedback from various people that they have
difficulty to write efficient Bazel rules. There is no single root cause, but
-it’s due to a combination of historical circumstances and intrinsic complexity
+it's due to a combination of historical circumstances and intrinsic complexity
in the problem domain. This document attempts to give a high level overview of
the specific issues that we believe to be the main contributors.
@@ -105,8 +105,8 @@
interface (what attributes it has, types of attributes). There are some
exceptions where the API allows custom code to run during the loading phase to
compute implicit names of output files and implicit values of attributes. For
-example, a java_library rule named ‘foo’ implicitly generates an output named
-‘libfoo.jar’, which can be referenced from other rules in the build graph.
+example, a java_library rule named 'foo' implicitly generates an output named
+'libfoo.jar', which can be referenced from other rules in the build graph.
Furthermore, the analysis of a rule cannot read any source files or inspect the
output of an action; instead, it needs to generate a partial directed bipartite
@@ -121,7 +121,7 @@
still up-to-date. The same is true for package loading and rule analysis, and we
have designed [Skyframe] (https://bazel.build/designs/skyframe.html) to handle this
in general. Skyframe is a graph library and evaluation framework that takes a
-goal node (such as ‘build //foo with these options’), and breaks it down into
+goal node (such as 'build //foo with these options'), and breaks it down into
its constituent parts, which are then evaluated and combined to yield this
result. As part of this process, Skyframe reads packages, analyzes rules, and
executes actions.
@@ -137,12 +137,12 @@
node can declare dependencies, and then use the contents of those dependencies
to declare even further dependencies. In principle, this maps well to a
thread-per-node model. However, medium-sized builds contain hundreds of
-thousands of Skyframe nodes, which isn’t easily possible with current Java
-technology (and for historical reasons, we’re currently tied to using Java, so
+thousands of Skyframe nodes, which isn't easily possible with current Java
+technology (and for historical reasons, we're currently tied to using Java, so
no lightweight threads and no continuations).
Instead, Bazel uses a fixed-size thread pool. However, that means that if a node
-declares a dependency that isn’t available yet, we may have to abort that
+declares a dependency that isn't available yet, we may have to abort that
evaluation and restart it (possibly in another thread), when the dependency is
available. This, in turn, means that nodes should not do this excessively; a
node that declares N dependencies serially can potentially be restarted N times,
@@ -150,12 +150,12 @@
dependencies, which sometimes requires reorganizing the code, or even splitting
a node into multiple nodes to limit the number of restarts.
-Note that this technology isn’t currently available in the rules API; instead,
+Note that this technology isn't currently available in the rules API; instead,
the rules API is still defined using the legacy concepts of loading, analysis,
and execution phases. However, a fundamental restriction is that all accesses to
other nodes have to go through the framework so that it can track the
corresponding dependencies. Regardless of the language in which the build system
-is implemented or in which the rules are written (they don’t have to be the
+is implemented or in which the rules are written (they don't have to be the
same), rule authors must not use standard libraries or patterns that bypass
Skyframe. For Java, that means avoiding java.io.File as well as any form of
reflection, and any library that does either. Libraries that support dependency
@@ -189,7 +189,7 @@
2. Binary Rules Depending on the Same Library Rules -
Consider the case where a set of binaries that depend on the same library
rules; for example, you might have a number of test rules that test the same
-library code. Let’s say out of N rules, half the rules are binary rules, and
+library code. Let's say out of N rules, half the rules are binary rules, and
the other half library rules. Now consider that each binary makes a copy of
some property computed over the transitive closure of library rules, such as
the Java runtime classpath, or the C++ linker command line. For example, it
@@ -203,7 +203,7 @@
custom collection classes that effectively compress the information in memory by
avoiding the copy at each step. Almost all of these data structures have set
semantics, so we called the class NestedSet. The majority of changes to reduce
-Bazel’s memory consumption over the past several years were changes to use
+Bazel's memory consumption over the past several years were changes to use
NestedSet instead of whatever was previously used.
Unfortunately, usage of NestedSet does not automatically solve all the issues;
diff --git a/site/docs/skylark/bzl-style.md b/site/docs/skylark/bzl-style.md
index b5d178d..ae623d6 100644
--- a/site/docs/skylark/bzl-style.md
+++ b/site/docs/skylark/bzl-style.md
@@ -33,7 +33,7 @@
Do not create a macro just to avoid some amount of repetition in BUILD files.
The [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) principle
-doesn’t really apply here. The goal is not to make the file shorter; the goal is
+doesn't really apply here. The goal is not to make the file shorter; the goal is
to make your files easy to process, both by humans and tools.
## General advice
@@ -117,7 +117,7 @@
build - macros are expanded _before Bazel does any build graph analysis._
Because of this, when something goes wrong, the user will need to understand
-your macro’s implementation to troubleshoot build problems. Additionally, `bazel
+your macro's implementation to troubleshoot build problems. Additionally, `bazel
query` results can be hard to interpret because targets shown in the results
come from macro expansion. Finally, aspects are not aware of macros, so tooling
depending on aspects (IDEs and others) might fail.
@@ -148,7 +148,7 @@
Engineers often write macros when the Starlark API of relevant rules is
insufficient for their specific use case, regardless of whether the rule is
-defined within Bazel in native code, or in Starlark. If you’re facing this
+defined within Bazel in native code, or in Starlark. If you're facing this
problem, ask the rule author if they can extend the API to accomplish your
goals.
@@ -156,8 +156,8 @@
## Rules
-* Rules, aspects, and their attributes should use lower_case names (“snake
- case”).
+* Rules, aspects, and their attributes should use lower_case names ("snake
+ case").
* Rule names are nouns that describe the main kind of artifact produced by the
rule, from the point of view of its dependencies (or for leaf rules, the
user). This is not necessarily a file suffix. For instance, a rule that
diff --git a/site/docs/skylark/config.md b/site/docs/skylark/config.md
index 9d3be14..4599603 100644
--- a/site/docs/skylark/config.md
+++ b/site/docs/skylark/config.md
@@ -314,7 +314,7 @@
### Defining Transitions in Starlark
Transitions define configuration changes between rules. For example, a request
-like “compile my dependency for a different CPU than its parent” is handled by a
+like "compile my dependency for a different CPU than its parent" is handled by a
transition.
Formally, a transition is a function from an input configuration to one or more
diff --git a/site/docs/skylark/testing.md b/site/docs/skylark/testing.md
index fe4cfc2..d702803 100644
--- a/site/docs/skylark/testing.md
+++ b/site/docs/skylark/testing.md
@@ -39,10 +39,10 @@
tests.
The basic principle is to define a testing rule that depends on the
-rule-under-test. This gives the testing rule access to the rule-under-test’s
+rule-under-test. This gives the testing rule access to the rule-under-test's
providers.
-The testing rule’s implementation function carries out assertions. If there are
+The testing rule's implementation function carries out assertions. If there are
any failures, these are not raised immediately by calling `fail()` (which would
trigger an analysis-time build error), but rather by storing the errors in a
generated script that fails at test execution time.
@@ -171,7 +171,7 @@
should be prefixed with `foo_` (`provider_contents_`)
Note that the labels of all targets can conflict with other labels in the same
-BUILD package, so it’s helpful to use a unique name for the test.
+BUILD package, so it's helpful to use a unique name for the test.
### Failure Testing
@@ -278,7 +278,7 @@
add a `*_test` target to your BUILD file. The specific artifacts you want to
check should be data dependencies of this target. If your validation logic is
reusable for multiple tests, it should be a script that takes command line
-arguments that are controlled by the test target’s `args` attribute. Here’s an
+arguments that are controlled by the test target's `args` attribute. Here's an
example that validates that the output of `myrule` from above is `"abc"`.
`//mypkg/myrule_validator.sh`:
@@ -447,5 +447,5 @@
)
```
-For more examples, see Skylib’s own [tests](https://github.com/bazelbuild/bazel-skylib/blob/master/tests/BUILD).
+For more examples, see Skylib's own [tests](https://github.com/bazelbuild/bazel-skylib/blob/master/tests/BUILD).
diff --git a/site/docs/tutorial/cpp.md b/site/docs/tutorial/cpp.md
index 6c59f4d..6b869ae 100644
--- a/site/docs/tutorial/cpp.md
+++ b/site/docs/tutorial/cpp.md
@@ -275,7 +275,7 @@
### Use multiple packages
-Let’s now split the project into multiple packages. Take a look at the contents
+Let's now split the project into multiple packages. Take a look at the contents
of the `cpp-tutorial/stage3` directory:
```
diff --git a/site/docs/user-manual.html b/site/docs/user-manual.html
index f7e7c28..5b7b82a 100644
--- a/site/docs/user-manual.html
+++ b/site/docs/user-manual.html
@@ -2805,7 +2805,7 @@
WARNING: <code class='flag'>--batch</code> is deprecated. For build isolation, we recommend
using the command option <code class='flag'>--nokeep_state_after_build</code>, which guarantees
that no incremental in-memory state is kept between builds. In order to restart the
- Bazel server and JVM after a build, please explicitly do so using the “shutdown” command.
+ Bazel server and JVM after a build, please explicitly do so using the "shutdown" command.
</p>
<p>
diff --git a/src/main/java/com/google/devtools/build/lib/bazel/repository/downloader/HttpConnectorMultiplexer.java b/src/main/java/com/google/devtools/build/lib/bazel/repository/downloader/HttpConnectorMultiplexer.java
index b5bcabf..0ee9ba3 100644
--- a/src/main/java/com/google/devtools/build/lib/bazel/repository/downloader/HttpConnectorMultiplexer.java
+++ b/src/main/java/com/google/devtools/build/lib/bazel/repository/downloader/HttpConnectorMultiplexer.java
@@ -51,8 +51,8 @@
* <p>This is the most amazing way to download files ever. It makes Bazel builds as reliable as
* Blaze builds in Google's internal hermettically sealed repository. But this class isn't just
* reliable. It's also fast. It even works on the worst Internet connections in the farthest corners
- * of the Earth. You are just not going to believe how fast and reliable this design is. It’s
- * incredible. Your builds are never going to break again due to downloads. You’re going to be so
+ * of the Earth. You are just not going to believe how fast and reliable this design is. It's
+ * incredible. Your builds are never going to break again due to downloads. You're going to be so
* happy. Your developer community is going to be happy. Mr. Jenkins will be happy too. Everyone is
* going to have such a magnificent developer experience due to the product excellence of this
* class.
diff --git a/src/main/java/com/google/devtools/build/lib/rules/cpp/CcCompilationHelper.java b/src/main/java/com/google/devtools/build/lib/rules/cpp/CcCompilationHelper.java
index c8fc2b5..5428a78 100644
--- a/src/main/java/com/google/devtools/build/lib/rules/cpp/CcCompilationHelper.java
+++ b/src/main/java/com/google/devtools/build/lib/rules/cpp/CcCompilationHelper.java
@@ -1151,16 +1151,20 @@
* Calculate the output names for object file paths from a set of source files.
*
* <p>The object file path is constructed in the following format:
- * <bazel-bin>/<target_package_path>/_objs/<target_name>/<output_name>.<obj_extension>
- * When there's no two source files having the same basename:
- * <output_name> = <prefixDir>/<source_file_base_name>
- * otherwise:
- * <output_name> = <prefixDir>/N/<source_file_base_name>,
- * N = the file’s order among the source files with the same basename, starts with 0
+ * {@code <bazel-bin>/<target_package_path>/_objs/<target_name>/<output_name>.<obj_extension>}.
*
- * <p>Examples: 1. Output names for ["lib1/foo.cc", "lib2/bar.cc"] are ["foo", "bar"]
- * 2. Output names for ["foo.cc", "bar.cc", "foo.cpp", "lib/foo.cc"]
- * are ["0/foo", "bar", "1/foo", "2/foo"]
+ * <p>When there's no two source files having the same basename:
+ * {@code <output_name> = <prefixDir>/<source_file_base_name>}
+ * otherwise:
+ * {@code <output_name> = <prefixDir>/N/<source_file_base_name>,
+ * {@code N} = the file's order among the source files with the same basename, starts with 0
+ *
+ * <p>Examples:
+ * <ol>
+ * <li>Output names for ["lib1/foo.cc", "lib2/bar.cc"] are ["foo", "bar"]
+ * <li>Output names for ["foo.cc", "bar.cc", "foo.cpp", "lib/foo.cc"] are
+ * ["0/foo", "bar", "1/foo", "2/foo"]
+ * </ol>
*/
private ImmutableMap<Artifact, String> calculateOutputNameMap(
NestedSet<Artifact> sourceArtifacts, String prefixDir) {
diff --git a/src/main/java/com/google/devtools/build/lib/skyframe/RepositoryMappingValue.java b/src/main/java/com/google/devtools/build/lib/skyframe/RepositoryMappingValue.java
index 8311ac0..0561a79 100644
--- a/src/main/java/com/google/devtools/build/lib/skyframe/RepositoryMappingValue.java
+++ b/src/main/java/com/google/devtools/build/lib/skyframe/RepositoryMappingValue.java
@@ -27,16 +27,17 @@
import java.util.Objects;
/**
- * A value that represents the 'mappings' of an external Bazel workspace, as defined
- * in the main WORKSPACE file. The SkyValue contains the mappings themselves, with the key being
- * the name of the external repository.
+ * A value that represents the 'mappings' of an external Bazel workspace, as defined in the main
+ * WORKSPACE file. The SkyValue contains the mappings themselves, with the key being the name of the
+ * external repository.
*
* <p>Given the following rule:
+ *
* <pre>{@code
* local_repository(
- * name = “a”,
- * path = “../a”,
- * repo_mapping = {“@x” : “@y”}
+ * name = "a",
+ * path = "../a",
+ * repo_mapping = {"@x" : "@y"}
* )
* }</pre>
*
@@ -44,8 +45,8 @@
*
* <p>This is kept as a separate value with trivial change pruning so as to not necessitate a
* dependency from every {@link PackageValue} to the //external {@link PackageValue}, so that
- * changes to things in the WORKSPACE other than the mappings (and name) won't require reloading
- * all packages. If the mappings are changed then the external packages need to be reloaded.
+ * changes to things in the WORKSPACE other than the mappings (and name) won't require reloading all
+ * packages. If the mappings are changed then the external packages need to be reloaded.
*/
public class RepositoryMappingValue implements SkyValue {
