Copybara import of the project:

--
f071a05 by Arpit Jain <arpitjain099@gmail.com>:

docs: fix seven typos in design and overview docs

All caught by codespell on docs/, all in user-facing markdown (no code,
identifier renames, or API names):

  docs/design/design.md              filles -> files, diferent -> different, relevent -> relevant
  docs/design/thunks_...md           sigatures -> signatures
  docs/overview/limits.md            ohter -> other
  docs/overview/reference_safety.md  succintly -> succinctly
  docs/overview/unstable_features.md intialization -> initialization

False-positives in the same scan that I deliberately did NOT fix:
re-declared / re-declare (both forms are valid), unparseable (both 'parseable'
and 'parsable' forms are accepted), statics (a real C++ term).

Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
FUTURE_COPYBARA_INTEGRATE_REVIEW=#1021 from arpitjain099:docs/typos f071a05
PiperOrigin-RevId: 914860013

Author: arpitjain099

bazel/llvm.bzl

@@ -53,7 +53,7 @@ def _llvm_loader_repository(repository_ctx):
             executable = False,
         )
 
-LLVM_COMMIT_SHA = "87d42c13cd6b119240781f31e5869981d500a186"
+LLVM_COMMIT_SHA = "eeca78019189a5559a694bb4774fec3e6ae07096"
 
 def llvm_loader_repository_dependencies():
     # This *declares* the dependency, but it won't actually be *downloaded* unless it's used.

docs/design/design.md

@@ -226,7 +226,7 @@ language, as that provides the most natural way to define Rust APIs.
     C++ code.** When making changes to C++ code, engineers are less likely to
     notice and update the annotations in sidecar files.
     *   Presubmits can catch some cases of desynchronization between C++ headers
-        and sidecar filles. However, presubmit errors that remind engineers to
+        and sidecar files. However, presubmit errors that remind engineers to
         edit more files create an inferior user experience.
 *   **Sidecar files create extra friction to modify the code.** Where previously
     one had to edit only a C++ header and a C++ source file, now one also likely
@@ -377,7 +377,7 @@ the more library and team-specific interop customizations we will have to
 support, and the more it will make sense for the performance team to tweak
 generated code to implement sweeping optimizations. These kinds of changes
 should be readily possible, and they should not create conflicts of interest
-between diferent users of the interop tooling.
+between different users of the interop tooling.
 
 ### Interop tooling should facilitate C++ to Rust migration
 
@@ -570,7 +570,7 @@ C++ headers for Rust libraries which expose a public C API**.
         generation is driven by the build system (i.e. by Bazel, or Cargo, or
         GN/ninja, rather than manually) and that the integration between the FFI
         tools and the build system doesn't have any bugs (e.g. that it
-        faithfully replicates all relevent compilation flags).
+        faithfully replicates all relevant compilation flags).
 
 **Evaluation**
 

docs/design/thunks_for_class_template_member_functions.md

@@ -109,7 +109,7 @@ Cons:
 
 -   **Assumes a particular ABI** - a function template specialization uses the
     calling convention prescribed by the platform C++ ABI.  We know that
-    [the Itanium ABI maps C++ sigatures to the C
+    [the Itanium ABI maps C++ signatures to the C
     ABI](https://itanium-cxx-abi.github.io/cxx-abi/abi.html#functions) and
     therefore will be compatible with the calling convention expected by the
     generated `..._rs_api.rs`.  Further research is needed to investigate the

docs/overview/limits.md

@@ -235,7 +235,7 @@ takes the form of implementation-specific attributes which the compiler can read
 to inform what warnings to give.
 
 It is possible to lose safety unless FFI correctly propagates the relevant
-information to the ohter side. And in Rust, incorrectly marking functions as
+information to the other side. And in Rust, incorrectly marking functions as
 unsafe can lead to safety fatigue, where most calls are trivially correct, and
 the few that aren't have insufficient review.
 

docs/overview/reference_safety.md

@@ -44,7 +44,7 @@ Examples of C++ features that may mutate a value that Rust holds a reference to:
     reference to.
 *   Mutating public fields of a C++ struct that Rust has a reference to.
 
-TODO: Try to succintly mention the idea that short-lived / non-retained
+TODO: Try to succinctly mention the idea that short-lived / non-retained
 references are safe from the mutation risk.
 
 ## Dangling or null references

docs/overview/unstable_features.md

@@ -37,7 +37,7 @@ For each feature we use, we document the following:
 ### `negative_impls`
 
 *   **Crubit feature:** `supported`
-*   **Use case:** Used to implement `ctor` / nontrivial intialization, so that
+*   **Use case:** Used to implement `ctor` / nontrivial initialization, so that
     we can dispatch on the existence of the `SelfCtor` trait. Also used so that
     we can pin/unpin a type without adding a field (which is not possible with
     `PhantomPinned`).