Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion bazel/llvm.bzl
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
6 changes: 3 additions & 3 deletions docs/design/design.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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

Expand Down Expand Up @@ -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**

Expand Down
2 changes: 1 addition & 1 deletion docs/design/thunks_for_class_template_member_functions.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion docs/overview/limits.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
2 changes: 1 addition & 1 deletion docs/overview/reference_safety.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion docs/overview/unstable_features.md
Original file line number Diff line number Diff line change
Expand Up @@ -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`).
Expand Down
Loading