diff --git a/content/GATs-stabilization-push/index.md b/content/GATs-stabilization-push/index.md index 79510b64a..3ceea3f3e 100644 --- a/content/GATs-stabilization-push/index.md +++ b/content/GATs-stabilization-push/index.md @@ -171,7 +171,7 @@ Ok, so now comes the part that nobody likes hearing about: the limitations. Fort fn takes_iter(_: &mut dyn for<'a> LendingIterator = &'a i32>) {} ``` -The biggest reason for this decision is that there's still a bit of design and implementation work to actually make this usable. And while this is a nice feature, adding this in the future would be a backward-compatible change. We feel that it's better to get *most* of GATs stabilized and then come back and try to tackle this later than to block GATs for even longer. Also, GATs without object safety are still very powerful, so we don't lose much by defering this. +The biggest reason for this decision is that there's still a bit of design and implementation work to actually make this usable. And while this is a nice feature, adding this in the future would be a backward-compatible change. We feel that it's better to get *most* of GATs stabilized and then come back and try to tackle this later than to block GATs for even longer. Also, GATs without object safety are still very powerful, so we don't lose much by deferring this. As was mentioned earlier in this post, there are still a couple remaining diagnostics [issues](https://github.com/rust-lang/rust/labels/F-generic_associated_types). If you do find bugs though, please file issues! diff --git a/content/Increasing-Rusts-Reach-2018.md b/content/Increasing-Rusts-Reach-2018.md index 6f026cf54..88c84343a 100644 --- a/content/Increasing-Rusts-Reach-2018.md +++ b/content/Increasing-Rusts-Reach-2018.md @@ -22,7 +22,7 @@ three (3) months, from mid-May to mid-August. Each partnership agrees to a commi 3-5 hours per week collaborating on a Rust project. By way of thanks for participating in the program, we offer a fully paid conference ticket, -travel, and accomodations for every participant to a Rust Conference of their choice: +travel, and accommodations for every participant to a Rust Conference of their choice: - May 26-27: [RustFest Paris] - August 16-17: [RustConf] diff --git a/content/Project-Goals-2025-July-Update.md b/content/Project-Goals-2025-July-Update.md index 30f670e3b..2cd554b72 100644 --- a/content/Project-Goals-2025-July-Update.md +++ b/content/Project-Goals-2025-July-Update.md @@ -1644,7 +1644,7 @@ The `stable_mir` crate is now `rustc_public`. We are now finalizing the infrastr -We made further progress on the new benchmarking scheme. The side of the website is nearing MVP status, currently we are switching focus on the side of the collector tha truns the benchmarks. +We made further progress on the new benchmarking scheme. The side of the website is nearing MVP status, currently we are switching focus on the side of the collector that runs the benchmarks. Some notable PRs: - Benchmark request queue for try builds and release artifacts (, , , ). @@ -1669,7 +1669,7 @@ Some notable PRs: -We made further progress on the new benchmarking scheme. The side of the website is nearing MVP status, currently we are switching focus on the side of the collector tha truns the benchmarks. +We made further progress on the new benchmarking scheme. The side of the website is nearing MVP status, currently we are switching focus on the side of the collector that runs the benchmarks. Some notable PRs: - Benchmark request queue for try builds and release artifacts (https://github.com/rust-lang/rustc-perf/pull/2166, https://github.com/rust-lang/rustc-perf/pull/2192, https://github.com/rust-lang/rustc-perf/pull/2197, https://github.com/rust-lang/rustc-perf/pull/2201). diff --git a/content/Project-Goals-Dec-Update.md b/content/Project-Goals-Dec-Update.md index 031f9d4ed..6a0de197f 100644 --- a/content/Project-Goals-Dec-Update.md +++ b/content/Project-Goals-Dec-Update.md @@ -47,7 +47,7 @@ For our other goals, we made progress, but there remains work to be done: We largely completed our goal to stabilize the language features used by the Rust for Linux project. In some cases a small amount of work remains. Over the last six months, we... * stabilized the `offset_of!` macro to get the offset of fields; -* *almost* stabilized the `CoercePointee` trait -- but [discovered that the current implementaton was revealing unstable details](https://github.com/rust-lang/rust/pull/133820#issuecomment-2559379796), which is currently being resolved; +* *almost* stabilized the `CoercePointee` trait -- but [discovered that the current implementation was revealing unstable details](https://github.com/rust-lang/rust/pull/133820#issuecomment-2559379796), which is currently being resolved; * `asm_goto` stabilization PR and reference updates are up, excluding the "output" feature. * completed the majority of the work for arbitrary self types, which is being used by RfL and just needs documentation before stabilisation diff --git a/content/Project-Goals-Feb-Update/index.md b/content/Project-Goals-Feb-Update/index.md index 3862a6a2d..4eb470521 100644 --- a/content/Project-Goals-Feb-Update/index.md +++ b/content/Project-Goals-Feb-Update/index.md @@ -173,7 +173,7 @@ We are also working to finalize the stabilization of the language features that
-3 detailed updates availabled. +3 detailed updates available. @@ -284,7 +284,7 @@ Updates from our [2025-02-12 meeting](https://hackmd.io/AkNBW942SoacLayPXHthCg): Given the recent controversy about Rust usage in the Kernel, the RFL group wrote up a [policy document explainer](https://rust-for-linux.com/rust-kernel-policy) to explain the policy, and there was a [write-up on LWN](https://lwn.net/SubscriberLink/1007921/9020dbb12585d48f/). -Regarding arbitary self types and coerce pointee, we are waiting on rust-lang/rust#136764 and rust-lang/rust#136776. The former is on lang team FCP. The latter has received approval from lang team and is awaiting further impl work by @BoxyUwU. +Regarding arbitrary self types and coerce pointee, we are waiting on rust-lang/rust#136764 and rust-lang/rust#136776. The former is on lang team FCP. The latter has received approval from lang team and is awaiting further impl work by @BoxyUwU. @ojeda is looking into how to manage dependency information and configure no-std externally. @@ -349,7 +349,7 @@ Help wanted: this project goal needs a compiler developer to move forward. *Help wanted:* this project goal needs someone to work on the implementation. If you'd like to help, please post in [this goal's dedicated zulip topic](https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/Prototype.20a.20new.20set.20of.20Cargo.20.22plumbing.22.20.28goals.23264.29).
-2 detailed updates availabled. +2 detailed updates available. @@ -947,7 +947,7 @@ This is, I believe, mostly waiting on us on the lang team to have a look, probab
-2 detailed updates availabled. +2 detailed updates available. @@ -1004,7 +1004,7 @@ Update (2025-02-27):
-2 detailed updates availabled. +2 detailed updates available. @@ -1393,7 +1393,7 @@ Last week at the Safety Critical Rust Consortium meeting in London, Ferrous syst
-2 detailed updates availabled. +2 detailed updates available. diff --git a/content/Rust-1.13/index.md b/content/Rust-1.13/index.md index ea9175e04..18fdd84bd 100644 --- a/content/Rust-1.13/index.md +++ b/content/Rust-1.13/index.md @@ -177,7 +177,7 @@ part of our toolbox! We can use this tool to look at a [graph] of performance over the 1.13 development cycle, shown below. This cycle covered the dates from August 16 -through September 29 (the graph begins from Augest 25th though and is filtered +through September 29 (the graph begins from August 25th though and is filtered in a few ways to eliminate bogus, incomplete, or confusing results). There appear to be some big reductions, which are quantified on the corresponding [statistics] page. diff --git a/content/Rust-1.16.md b/content/Rust-1.16.md index c8309aff2..80b875e01 100644 --- a/content/Rust-1.16.md +++ b/content/Rust-1.16.md @@ -52,7 +52,7 @@ There's a lot of them. However, you can think of this process in two big steps: all of its safety checks, makes sure your syntax is correct, all that stuff. Second, once it's satisfied that everything is in order, it produces the actual binary code that you end up executing. -It turns out that that second step takes a lot of time. And most of the time, it's not neccesary. That is, +It turns out that that second step takes a lot of time. And most of the time, it's not necessary. That is, when you're working on some Rust code, many developers will get into a workflow like this: 1. Write some code. diff --git a/content/Rust-1.17.md b/content/Rust-1.17.md index 66b60dfc4..a3f8898b4 100644 --- a/content/Rust-1.17.md +++ b/content/Rust-1.17.md @@ -166,7 +166,7 @@ step back we want to regretfully inform you about. On Windows, Visual Studio 2017 has been released, and Microsoft has changed the structure of how the software is installed. [Rust cannot automatically detect this location](https://github.com/rust-lang/rust/issues/38584), and while we -were working on the neccesary changes, they did not make it in time for +were working on the necessary changes, they did not make it in time for this release. Until then, Visual Studio 2015 still works fine, or you can run `vcvars.bat` on the command line. We hope to make this work in a seamless fashion soon. @@ -319,7 +319,7 @@ tools = [] ``` The `tools` feature allows us to include extra tooling, and the `postgres` and `sqlite` -features control which databses we want to support. +features control which databases we want to support. Previously, `cargo build` would attempt to build all targets, which is normally what you want. But what if we had a `src/bin/postgres-tool.rs`, that would only really diff --git a/content/Rust-1.24.1.md b/content/Rust-1.24.1.md index fbe36653c..a651aa218 100644 --- a/content/Rust-1.24.1.md +++ b/content/Rust-1.24.1.md @@ -54,7 +54,7 @@ in 1.24.0, you'll need to revert it for now. While we still plan to introduce this behavior eventually, we will be rolling it out more slowly and with a new implementation strategy. -Quoting [the 1.24 annoucement](https://blog.rust-lang.org/2018/02/15/Rust-1.24.html): +Quoting [the 1.24 announcement](https://blog.rust-lang.org/2018/02/15/Rust-1.24.html): > There’s one other change we’d like to talk about here: undefined behavior. > Rust generally strives to minimize undefined behavior, having none of it in @@ -120,7 +120,7 @@ into Lua is [wrapped with `lua_pcall`](https://www.lua.org/pil/24.3.2.html): So, the question becomes: Why does this break? And why does it break on Windows? -When we talked about `setjmp`/`longjmp` inititally, a key phrase here wasn't +When we talked about `setjmp`/`longjmp` initially, a key phrase here wasn't highlighted. Here it is: > After digging in, the culpurit was found: `setjmp`/`longjmp`. These functions @@ -192,7 +192,7 @@ we may backport, otherwise, this functionality will be back in 1.26. TL;DR: `rustc` stopped working for some Windows users in edge-case situations. If it's been working for you, you were not affected by this bug. -In constrast with the previous bug, which is very complex and tough to understand, +In contrast with the previous bug, which is very complex and tough to understand, this bug's impact is simple: if you have non-ASCII paths in the directory where you invoke `rustc`, in 1.24, it would incorrectly error with a message like diff --git a/content/Rust-1.32.0.md b/content/Rust-1.32.0.md index 5ac39a1d6..e1abb3bc6 100644 --- a/content/Rust-1.32.0.md +++ b/content/Rust-1.32.0.md @@ -125,7 +125,7 @@ n: 6 n: 24 ``` -This is servicable, but not particularly great. Maybe we could work on how we +This is serviceable, but not particularly great. Maybe we could work on how we print out the context to make it more clear, but now we're not debugging our code, we're figuring out how to make our debugging code better. @@ -161,7 +161,7 @@ Because the `dbg!` macro returns the value of what it's debugging, instead of of our code. Additionally, we have *vastly* more useful output. That's a lot to say about a little macro, but we hope it improves your -debugging experience! We are contining to work on support for `gdb` and +debugging experience! We are continuing to work on support for `gdb` and friends as well, of course. #### `jemalloc` is removed by default diff --git a/content/Rust-1.34.1.md b/content/Rust-1.34.1.md index 23a9554be..e839d885c 100644 --- a/content/Rust-1.34.1.md +++ b/content/Rust-1.34.1.md @@ -45,7 +45,7 @@ In the following snippet, the method `required` expects `dep: &D` but the actual dependencies.iter().filter(|dep| dep.required()); ``` -Clippy erronously suggested `.filter(Dependency::required)`, +Clippy erroneously suggested `.filter(Dependency::required)`, which is rejected by the compiler due to the difference in borrows. ### False positive in `clippy::missing_const_for_fn` diff --git a/content/Rust-1.60.0/index.md b/content/Rust-1.60.0/index.md index 8485c37ed..b5a3b1e25 100644 --- a/content/Rust-1.60.0/index.md +++ b/content/Rust-1.60.0/index.md @@ -41,7 +41,7 @@ RUSTFLAGS="-C instrument-coverage" cargo build After that, you can run the resulting binary, which will produce a `default.profraw` file in the current directory. (The path and filename can be -overriden by an environment variable; see +overridden by an environment variable; see [documentation](https://doc.rust-lang.org/stable/rustc/instrument-coverage.html#running-the-instrumented-binary-to-generate-raw-coverage-profiling-data) for details). diff --git a/content/Rustup-1.20.0.md b/content/Rustup-1.20.0.md index 09f898728..399b2c188 100644 --- a/content/Rustup-1.20.0.md +++ b/content/Rustup-1.20.0.md @@ -46,7 +46,7 @@ To change the rustup profile you can use the `rustup set profile` command. For e rustup set profile minimal ``` -It's also possible to choose the profile when installing rustup for the first time, either interactively by choosing the "Customize installation" option or programmaticaly by passing the `--profile=` flag. Profiles will only affect newly installed toolchains: as usual it will be possible to install individual components later with: `rustup component add`. +It's also possible to choose the profile when installing rustup for the first time, either interactively by choosing the "Customize installation" option or programmatically by passing the `--profile=` flag. Profiles will only affect newly installed toolchains: as usual it will be possible to install individual components later with: `rustup component add`. ### Installing the latest compatible nightly diff --git a/content/Rustup-1.24.3.md b/content/Rustup-1.24.3.md index ac73fa736..578a85d70 100644 --- a/content/Rustup-1.24.3.md +++ b/content/Rustup-1.24.3.md @@ -26,7 +26,7 @@ If you don't have it already, you can [get rustup][install] from the appropriate ## What's new in rustup 1.24.3 -This patch release focusses around resolving some regressions in behaviour in +This patch release focuses around resolving some regressions in behaviour in the 1.24.x series, in either low tier platforms, or unusual situations around very old toolchains. diff --git a/content/Security-advisory.md b/content/Security-advisory.md index bb6ed9fef..c30e2e3d5 100644 --- a/content/Security-advisory.md +++ b/content/Security-advisory.md @@ -82,7 +82,7 @@ resolve this in the standard library soon. ## Timeline of events * Thu, May 9, 2019 at 14:07 PM - Bug reported to security@rust-lang.org -* Thu, May 9, 2019 at 15:10 PM - Alex reponds, confirming the bug +* Thu, May 9, 2019 at 15:10 PM - Alex responds, confirming the bug * Fri, May 10, 2019 - Plan for mitigation developed and implemented * Mon, May 13, 2019 - PRs posted to GitHub for [stable][3]/[beta][4]/[master][5] branches * Mon, May 13, 2019 - Security list informed of this issue diff --git a/content/all-hands.md b/content/all-hands.md index 1811951fa..9a498dff2 100644 --- a/content/all-hands.md +++ b/content/all-hands.md @@ -121,7 +121,7 @@ process]. ### WG: network services - [WG overview slides](https://gist.github.com/withoutboats/6d4c4639b286d3da19d89d8af82d82d7). -- **Launching the WG**: determined goals for the WG, including async/await, documentaiton, mid-level HTTP libraries, and the [Tower](https://github.com/tower-rs/tower) ecosystem. +- **Launching the WG**: determined goals for the WG, including async/await, documentation, mid-level HTTP libraries, and the [Tower](https://github.com/tower-rs/tower) ecosystem. Kickoff announcement coming soon! - **Async/await**: finalized design and stabilization approach for RFCs (blog post and links to RFCs [here](https://boats.gitlab.io/blog/post/2018-04-06-async-await-final/)). diff --git a/content/cargo-cves.md b/content/cargo-cves.md index 673c4f414..72a4d4f30 100644 --- a/content/cargo-cves.md +++ b/content/cargo-cves.md @@ -13,7 +13,7 @@ aliases = ["2022/09/14/cargo-cves.html"] The Rust Security Response WG was notified that Cargo did not prevent extracting some malformed packages downloaded from alternate registries. An attacker able to upload packages to an alternate registry could fill the -filesystem or corrupt arbitary files when Cargo downloaded the package. +filesystem or corrupt arbitrary files when Cargo downloaded the package. These issues have been assigned CVE-2022-36113 and CVE-2022-36114. The severity of these vulnerabilities is "low" for users of alternate registries. Users @@ -30,7 +30,7 @@ macros. After a package is downloaded, Cargo extracts its source code in the `~/.cargo` folder on disk, making it available to the Rust projects it builds. To record -when an extraction is successfull, Cargo writes "ok" to the `.cargo-ok` file at +when an extraction is successful, Cargo writes "ok" to the `.cargo-ok` file at the root of the extracted source code once it extracted all the files. It was discovered that Cargo allowed packages to contain a `.cargo-ok` @@ -60,7 +60,7 @@ their own toolchains. ## Mitigations -We recommend users of alternate registries to excercise care in which package +We recommend users of alternate registries to exercise care in which package they download, by only including trusted dependencies in their projects. Please note that even with these vulnerabilities fixed, by design Cargo allows arbitrary code execution at build time thanks to build scripts and procedural @@ -69,7 +69,7 @@ vulnerabilities. crates.io implemented server-side checks to reject these kinds of packages years ago, and there are no packages on crates.io exploiting these -vulnerabilities. crates.io users still need to excercise care in choosing their +vulnerabilities. crates.io users still need to exercise care in choosing their dependencies though, as the same concerns about build scripts and procedural macros apply here. diff --git a/content/conf-lineup@1.md b/content/conf-lineup@1.md index e14188f4b..4a5bb4af6 100644 --- a/content/conf-lineup@1.md +++ b/content/conf-lineup@1.md @@ -21,7 +21,7 @@ The second day is the main event, with [talks][rc-talks] at every level of expertise, covering basic and advanced techniques, experience reports, guidance on teaching, and interesting libraries. -[Tickets are still on sale!][rc-ticks] We offer a [scholarship][rc-schol] for those +[Tickets are still on sale!][rc-ticks] We offer a [scholarship][rc-scholar] for those who would otherwise find it difficult to attend. Join us in lovely Portland and hear about the latest developments in the Rust world! @@ -29,7 +29,7 @@ Follow us on Twitter [@rustconf](https://twitter.com/rustconf). [rc-talks]: http://rustconf.com/program.html [rc-ticks]: http://rustconf.com/register.html - [rc-schol]: https://tilde.wufoo.com/forms/rustconf-scholarships/ + [rc-scholar]: https://tilde.wufoo.com/forms/rustconf-scholarships/ ### April 29-30th & Sept 30-01: Rust Fest diff --git a/content/const-eval-safety-rule-revision.md b/content/const-eval-safety-rule-revision.md index 40ad5ecd7..54ae424bb 100644 --- a/content/const-eval-safety-rule-revision.md +++ b/content/const-eval-safety-rule-revision.md @@ -121,7 +121,7 @@ The details of the CTFE engine's value representation do not matter too much for discussion here. We merely note that earlier versions of the compiler silently accepted expressions that *seemed to* transmute memory addresses into integers, copied them around, and then transmuted them back into addresses; but that was -not what was acutally happening under the hood. Instead, what was happening was +not what was actually happening under the hood. Instead, what was happening was that the values were passed around blindly (after all, the whole point of transmute is that it does no transformation on its input value, so it is a no-op in terms of its operational semantics). @@ -274,7 +274,7 @@ We have [performed][crater results] a [crater run] for the 1.64-beta and that di instances of this particular problem. If you can test compiling your crate atop the 1.64-beta before the stable release goes out on September 22nd, all the better! One easy way to try the beta -is to use [rustup's override shortand][rustup] for it: +is to use [rustup's override shorthand][rustup] for it: ```sh $ rustup update beta diff --git a/content/crates.io-malicious-crates-fasterlog-and-asyncprintln.md b/content/crates.io-malicious-crates-fasterlog-and-asyncprintln.md index fc316f0ff..1d5730225 100644 --- a/content/crates.io-malicious-crates-fasterlog-and-asyncprintln.md +++ b/content/crates.io-malicious-crates-fasterlog-and-asyncprintln.md @@ -18,7 +18,7 @@ These crates were: - `faster_log` - Published on May 25th, 2025, downloaded 7181 times - `async_println` - Published on May 25th, 2025, downloaded 1243 times -The malicious code was executed at runtime, when running or testing a project depending on them. Notably, they did not execute any malicious code at build time. Except for their malicious payload, these crates copied the source code, features, and documentation of legitimate crates, using a similiar name to them (a case of typosquatting[^typosquatting]). +The malicious code was executed at runtime, when running or testing a project depending on them. Notably, they did not execute any malicious code at build time. Except for their malicious payload, these crates copied the source code, features, and documentation of legitimate crates, using a similar name to them (a case of typosquatting[^typosquatting]). ## Actions taken diff --git a/content/cve-2024-24576.md b/content/cve-2024-24576.md index 47c827e07..a41bf7e13 100644 --- a/content/cve-2024-24576.md +++ b/content/cve-2024-24576.md @@ -28,7 +28,7 @@ On Windows, the implementation of this is more complex than other platforms, because the Windows API only provides a single string containing all the arguments to the spawned process, and it's up to the spawned process to split them. Most programs use the standard C run-time argv, which in practice results -in a mostly consistent way arguments are splitted. +in a mostly consistent way arguments are split. One exception though is `cmd.exe` (used among other things to execute batch files), which has its own argument splitting logic. That forces the standard diff --git a/content/edition-2021.md b/content/edition-2021.md index ac6b1955d..b390315a4 100644 --- a/content/edition-2021.md +++ b/content/edition-2021.md @@ -244,7 +244,7 @@ will be the only way to panic with something other than a formatted string. In addition, `core::panic!()` and `std::panic!()` will be identical in Rust 2021. Currently, there are some historical differences between those two, -which can be noticable when switching `#![no_std]` on or off. +which can be noticeable when switching `#![no_std]` on or off. ### Reserving syntax diff --git a/content/five-years-of-rust/index.md b/content/five-years-of-rust/index.md index e5a3e5040..279cb1452 100644 --- a/content/five-years-of-rust/index.md +++ b/content/five-years-of-rust/index.md @@ -410,7 +410,7 @@ asked some of our teams what changes they are most proud of: > * The search itself and its optimizations (last one being to convert it into JSON) > * The possibility to test more accurately doc code blocks "compile_fail, > should_panic, allow_fail" -> * Doc tests are now generated as their own seperate binaries. +> * Doc tests are now generated as their own separate binaries. > > — Guillaume Gomez ([rustdoc]) diff --git a/content/gats-stabilization.md b/content/gats-stabilization.md index 5418d5725..42a8c713c 100644 --- a/content/gats-stabilization.md +++ b/content/gats-stabilization.md @@ -30,7 +30,7 @@ Most of this should look familiar; this trait looks *very* similar to the [`Iter In general, GATs provide a foundational basis for a vast range of patterns and APIs. If you really want to get a feel for how many projects have been blocked on GATs being stable, go scroll through either the [tracking issue]: you will find numerous issues from other projects linking to those threads over the years saying something along the lines of "we want the API to look like X, but for that we need GATs" (or see [this comment](https://github.com/rust-lang/rust/pull/96709#issuecomment-1173170243) that has some of these put together already). If you're interested in how GATs enable a library to do zero-copy parsing, resulting in nearly a ten-fold performance increase, you might be interested in checking out a [blog post][chumsky_blog_post] on it by Niko Matsakis. -All in all, even if *you* won't need to use GATs directly, it's very possible that the *libraries* you use will use GATs either internally or publically for ergonomics, performance, or just because that's the only way the implementation works. +All in all, even if *you* won't need to use GATs directly, it's very possible that the *libraries* you use will use GATs either internally or publicly for ergonomics, performance, or just because that's the only way the implementation works. ## When GATs go wrong - a few current bugs and limitations diff --git a/content/i128-layout-update.md b/content/i128-layout-update.md index 67088d248..3e5100162 100644 --- a/content/i128-layout-update.md +++ b/content/i128-layout-update.md @@ -133,7 +133,7 @@ among other languages, and it has the alignment for `i128` hardcoded to 8 bytes. Clang uses the correct alignment only because of a workaround, where the alignment is manually set to 16 bytes before handing the type to LLVM. This fixes the layout issue but has been the source of some other minor problems.[^f128-segfault][^va-segfault] -Rust does no such manual adjustement, hence the issue reported at +Rust does no such manual adjustment, hence the issue reported at . # The Calling Convention Problem @@ -275,7 +275,7 @@ to avoid an increased memory footprint. # Compatibility -The most imporant question is how compatibility changed as a result of these fixes. In +The most important question is how compatibility changed as a result of these fixes. In short, `i128` and `u128` with Rust using LLVM 18 (the default version starting with 1.78) will be completely compatible with any version of GCC, as well as Clang 18 and above (released March 2024). All other combinations have some incompatible cases, which diff --git a/content/inside-rust/2025-leadership-council-survey.md b/content/inside-rust/2025-leadership-council-survey.md index bacf57fa3..bba09b800 100644 --- a/content/inside-rust/2025-leadership-council-survey.md +++ b/content/inside-rust/2025-leadership-council-survey.md @@ -21,7 +21,7 @@ our duties. > listed in this RFC and any subsequent revisions thereof to determine if the > Council is meeting its duties and obligations. -We are runnning a quick annual survey, primarily for Rust project members to +We are running a quick annual survey, primarily for Rust project members to provide feedback on the Leadership Council. However, even if you are not a member, feel free to fill out the survey too -- we welcome input from those interacting with the Council in other capacities. diff --git a/content/inside-rust/AsyncAwait-Not-Send-Error-Improvements.md b/content/inside-rust/AsyncAwait-Not-Send-Error-Improvements.md index ef1f755f2..b056e97d2 100644 --- a/content/inside-rust/AsyncAwait-Not-Send-Error-Improvements.md +++ b/content/inside-rust/AsyncAwait-Not-Send-Error-Improvements.md @@ -44,7 +44,7 @@ fn main() { } ``` -When we try to compile this, we'll get an unwieldly and hard-to-follow diagnostic: +When we try to compile this, we'll get an unwieldy and hard-to-follow diagnostic: ``` error[E0277]: `std::sync::MutexGuard<'_, u32>` cannot be sent between threads safely diff --git a/content/inside-rust/Concluding-events-mods.md b/content/inside-rust/Concluding-events-mods.md index b4aa85cb6..28bf3dad4 100644 --- a/content/inside-rust/Concluding-events-mods.md +++ b/content/inside-rust/Concluding-events-mods.md @@ -9,7 +9,7 @@ team = "The Moderation Team" team_url = "https://www.rust-lang.org/governance/teams/moderation" +++ -[With the moderators' resignation in November](https://blog.rust-lang.org/inside-rust/2021/11/25/in-response-to-the-moderation-team-resignation.html), we (Josh Gould and Khionu Sybiern) had the mantle of the Moderation Team offered to us, and we caught up to speed on what led up to this conflict. Their resignation became a catalyst, and we commited with the rest of the project leadership to do our best to solve the issues present and going forward. +[With the moderators' resignation in November](https://blog.rust-lang.org/inside-rust/2021/11/25/in-response-to-the-moderation-team-resignation.html), we (Josh Gould and Khionu Sybiern) had the mantle of the Moderation Team offered to us, and we caught up to speed on what led up to this conflict. Their resignation became a catalyst, and we committed with the rest of the project leadership to do our best to solve the issues present and going forward. After these months, the following update was shared with core and team leaders: diff --git a/content/inside-rust/Governance-WG-updated.md b/content/inside-rust/Governance-WG-updated.md index 01ce47f0a..b7d5d42c4 100644 --- a/content/inside-rust/Governance-WG-updated.md +++ b/content/inside-rust/Governance-WG-updated.md @@ -20,7 +20,7 @@ The agenda included: You can find the [detailed minutes](https://github.com/rust-lang/wg-governance/blob/master/minutes/2020.04.09.md) on the [wg-governance](https://github.com/rust-lang/wg-governance) repository, but here is a quick summary: * Follow up on the [Project Group RFC](https://github.com/rust-lang/rfcs/pull/2856) - * Defined roles of "lead" and "liason" + * Defined roles of "lead" and "liaison" * Discussed the initial Pre-RFC process draft * We ran out of time before getting to the Domain Working Group retrospective, but look forward to covering it at the next meeting! diff --git a/content/inside-rust/Lang-team-july-update.md b/content/inside-rust/Lang-team-july-update.md index ebfdac762..fb7eebff9 100644 --- a/content/inside-rust/Lang-team-july-update.md +++ b/content/inside-rust/Lang-team-july-update.md @@ -35,7 +35,7 @@ Did you know that you can see the lang team's active initiatives on our [project - [FFI Unwind:](https://github.com/rust-lang/lang-team/issues/19#issuecomment-875772875) - There is a pending PR that, when landed, closes all remaining issues with "C-unwind", clearing the way for possible stabilization. - [Inline assembly:](https://github.com/rust-lang/lang-team/issues/20) - - There are still a few active blockers, but there is also some discusison on the thread of a "minimum inline assembly" stabilization that could proceed in the near future! + - There are still a few active blockers, but there is also some discussions on the thread of a "minimum inline assembly" stabilization that could proceed in the near future! - [`#[instruction_set]` attribute:](https://github.com/rust-lang/rust/issues/74727) - The implementation is complete but doesn't produce optimal code. We are considering whether to stabilize in its current form, since it may be of use. **We are actively seeking feedback and experimentation from folks who might be interested in using this feature, which allows you to specify the instruction set for a particular function.** diff --git a/content/inside-rust/Lang-team-meeting@1.md b/content/inside-rust/Lang-team-meeting@1.md index f2878805a..160067c1b 100644 --- a/content/inside-rust/Lang-team-meeting@1.md +++ b/content/inside-rust/Lang-team-meeting@1.md @@ -34,7 +34,7 @@ tracking, along with weekly updates on the latest developments. permit unwinding by default - trying to get measurements of the impact on code size - prototyped the plan in a rustc branch, but needs a few updates and to be executed - on a representative code base (likely Fuschia) + on a representative code base (likely Fuchsia) * [Coherence can be bypassed by an indirect impl for a trait object](https://github.com/rust-lang/rust/issues/57893) - did a [crater run of the proposal](https://github.com/rust-lang/rust/pull/66037#issuecomment-549575983) but have only partially analyzed the impact * grammar working group — qmx diff --git a/content/inside-rust/Portable-SIMD-PG.md b/content/inside-rust/Portable-SIMD-PG.md index 8a3a7139a..55030b004 100644 --- a/content/inside-rust/Portable-SIMD-PG.md +++ b/content/inside-rust/Portable-SIMD-PG.md @@ -45,7 +45,7 @@ The details of what's available depend on the build target. We intend to release the Portable SIMD API as `std::simd`. We will cover as many use cases as we can, but it might still be appropriate for you to use `std::arch` directly. -For that reason the `std::simd` types will also be easily convertable to `std::arch` types where needed. +For that reason the `std::simd` types will also be easily convertible to `std::arch` types where needed. ## How can I get involved? diff --git a/content/inside-rust/Splitting-const-generics.md b/content/inside-rust/Splitting-const-generics.md index ac1e09e1b..5bf00e8a8 100644 --- a/content/inside-rust/Splitting-const-generics.md +++ b/content/inside-rust/Splitting-const-generics.md @@ -47,7 +47,7 @@ While allowing such things is desired, it adds additional complications exceedin There are still two major blockers for stabilization: -The first being the [transition to valtrees](https://github.com/rust-lang/rust/pull/83234). Valtrees are a representation of values as trees with integer nodes, simplifiying the way we interact with more complex types. +The first being the [transition to valtrees](https://github.com/rust-lang/rust/pull/83234). Valtrees are a representation of values as trees with integer nodes, simplifying the way we interact with more complex types. Additionally, we have to figure out which types we *even want* to allow as const parameter types. This ties into the discussion about ["structural match"](https://github.com/rust-lang/rust/issues/74446), which is still ongoing. diff --git a/content/inside-rust/What-the-error-handling-project-group-is-working-on.md b/content/inside-rust/What-the-error-handling-project-group-is-working-on.md index 195fc1e08..76647388f 100644 --- a/content/inside-rust/What-the-error-handling-project-group-is-working-on.md +++ b/content/inside-rust/What-the-error-handling-project-group-is-working-on.md @@ -17,7 +17,7 @@ Our first few meetings saw us setting a number of short- and long-term goals. Th ## One Standardized `Error` Trait -The `Error` trait has been around since 1.0, and exposed two methods: `Error::description` and `Error::cause`. As it was originally constructed, it was too restictive for a number of reasons1. The `Failure` crate addressed many of the `Error` trait's shortcomings by exporting the `Fail` trait, which informs many of changes that are being made to improve the `Error` trait. +The `Error` trait has been around since 1.0, and exposed two methods: `Error::description` and `Error::cause`. As it was originally constructed, it was too restrictive for a number of reasons1. The `Failure` crate addressed many of the `Error` trait's shortcomings by exporting the `Fail` trait, which informs many of changes that are being made to improve the `Error` trait. On that note, bolstering the `std::error::Error` trait such that it could be adopted across the Rust community as _the_ `Error` trait has been an ongoing process since [RFC 2504][rfc2504] was merged in August 2018. diff --git a/content/inside-rust/announcing-the-docsrs-team.md b/content/inside-rust/announcing-the-docsrs-team.md index 768b64f03..de8d20d48 100644 --- a/content/inside-rust/announcing-the-docsrs-team.md +++ b/content/inside-rust/announcing-the-docsrs-team.md @@ -22,7 +22,7 @@ the new Docs.rs Team, leaving [@GuillaumeGomez] to lead the Rustdoc Team. Joining QuietMisdreavus on the Docs.rs Team is GuillaumeGomez, coordinating work between Rustdoc and Docs.rs; [@onur], the original creator of Docs.rs; [@pietroalbini], who has coordinated work in -Docs.rs from the perspective of the Infrastrucure Team; and introducing [@jyn514], who has worked to +Docs.rs from the perspective of the Infrastructure Team; and introducing [@jyn514], who has worked to improve the developer experience of contributing to Docs.rs by converting the local development configuration to use `docker-compose`! diff --git a/content/inside-rust/compiler-team-2022-midyear-report.md b/content/inside-rust/compiler-team-2022-midyear-report.md index 0adbe0e1e..a834a1d16 100644 --- a/content/inside-rust/compiler-team-2022-midyear-report.md +++ b/content/inside-rust/compiler-team-2022-midyear-report.md @@ -814,7 +814,7 @@ and in other cases, what we learn of their usage is informing our plans going fo **Regarding prioritization and focus:** @estebank has seen people come contribute a handful of PRs and disappear, but has not dug deeper into their reasons. -The most common thing is people picking up a project that’s too advanced for them, which demotivates them. We try to both steer them away beforehands and to closely mentor them as they work on things. A cleaner codebase with more machinery for non-standard things (like typechecking opportunistically in the parser, to give an example of something impossible to do today) would allow some of the things people have tried to be done by almost anyone. +The most common thing is people picking up a project that’s too advanced for them, which demotivates them. We try to both steer them away beforehand and to closely mentor them as they work on things. A cleaner codebase with more machinery for non-standard things (like typechecking opportunistically in the parser, to give an example of something impossible to do today) would allow some of the things people have tried to be done by almost anyone. @estebank believes that diagnostics are super important and everyone's concern. Efforts like librarification could unblock very powerful heuristics to massively improve our user experience here, but such a project *shouldn't* be started *only* for diagnostics improvements (as there's plenty of things to do already). diff --git a/content/inside-rust/compiler-team-ambitions-2022.md b/content/inside-rust/compiler-team-ambitions-2022.md index b97355aa7..fd038d819 100644 --- a/content/inside-rust/compiler-team-ambitions-2022.md +++ b/content/inside-rust/compiler-team-ambitions-2022.md @@ -210,7 +210,7 @@ The Rust compiler's end-to-end latency is known to be a problem. ### Expressiveness Initiatives (👩‍💻, 🦀) A common refrain we hear is: "I need feature X, but it's not implemented in rustc or stable." -In Rust, we use an open Request-for-Comment (RFC) process for designing new features. Currently, we have [this set of RFCs approved][RFC tracking issue list]; here are some imporant features with dedicated owners that we expect forward movement on. +In Rust, we use an open Request-for-Comment (RFC) process for designing new features. Currently, we have [this set of RFCs approved][RFC tracking issue list]; here are some important features with dedicated owners that we expect forward movement on. [RFC tracking issue list]: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AC-tracking-issue++label%3AB-RFC-approved+ @@ -309,7 +309,7 @@ Reach out to [xldenis], from the LMF at the University of Paris-Saclay (and co-l #### MCVE reduction tooling -One common task for compiler developers is to create a [minimal complete verifiable example][E-needs-mcve]. This task is largely mechanical; pnkfelix has a [blog post][mcve blog post] about Rust source-to-source tranformations that accomplish this. But despite its mechanical nature, the current state of the art in automating this task is in tools like [creduce](https://github.com/csmith-project/creduce), which have some big limitations (such as only working on a single file at a time). +One common task for compiler developers is to create a [minimal complete verifiable example][E-needs-mcve]. This task is largely mechanical; pnkfelix has a [blog post][mcve blog post] about Rust source-to-source transformations that accomplish this. But despite its mechanical nature, the current state of the art in automating this task is in tools like [creduce](https://github.com/csmith-project/creduce), which have some big limitations (such as only working on a single file at a time). This is an area where you do not need any knowledge of the `rustc` source code at all. Anyone with an interest in programming language technology can get involved; e.g. one might consider adding IDE commands for certain code reducing transformations. @@ -355,7 +355,7 @@ If you are interested in helping out with this project, reach out to [antoyo] an ### Diagnostics Aspirations (👩‍💻) -The Rust compiler has pretty good diagnotics. But the good news is, there's a [full employment theorem](https://en.wikipedia.org/wiki/Full_employment_theorem) for diagnostics engineers which is supported by the 1,500+ [open diagnostics issues](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AA-diagnostics) we have. +The Rust compiler has pretty good diagnostics. But the good news is, there's a [full employment theorem](https://en.wikipedia.org/wiki/Full_employment_theorem) for diagnostics engineers which is supported by the 1,500+ [open diagnostics issues](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AA-diagnostics) we have. Diagnostics improvements are an *excellent* first step for learning about how to contribute to the Rust compiler. If you're interested in helping out but don't have any idea where to start, fixing diagnostic bugs is a great jumping off point, and you can reach out to [estebank] to find out more about how to help. @@ -364,7 +364,7 @@ Diagnostics improvements are an *excellent* first step for learning about how to Reading over this list, the number of items on it seems quite daunting! We believe these initiatives will provide the highest impact to the Rust community by helping to fulfill Rust's promise, delighting Rust developers and improving our contributor workflows and aligns well with the results of the [2021 Rust Survey](https://blog.rust-lang.org/2022/02/15/Rust-Survey-2021.html). -While we think we will be able to make signficant progress on these initiatives this year, project estimation is a difficult and inexact science, especially for open source projects. What we will achieve is ultimately a result of who decides to contribute. Our aspirational goals are currently just that: aspirations. +While we think we will be able to make significant progress on these initiatives this year, project estimation is a difficult and inexact science, especially for open source projects. What we will achieve is ultimately a result of who decides to contribute. Our aspirational goals are currently just that: aspirations. This is where you all, the Rust community (including *future members* of that community) come into the picture. Each item has one or two people listed with it; if you're feeling inspired, please do contact us! diff --git a/content/inside-rust/compiler-team-feb-steering-cycle.md b/content/inside-rust/compiler-team-feb-steering-cycle.md index 208a2774f..a560edb82 100644 --- a/content/inside-rust/compiler-team-feb-steering-cycle.md +++ b/content/inside-rust/compiler-team-feb-steering-cycle.md @@ -2,7 +2,7 @@ path = "inside-rust/2023/02/10/compiler-team-feb-steering-cycle" title = "Rust Compiler February 2023 Steering Cycle" authors = ["Felix Klock"] -description = "The compiler team's Feburary 2023 steering cycle" +description = "The compiler team's February 2023 steering cycle" aliases = ["inside-rust/2023/02/10/compiler-team-feb-steering-cycle.html"] [extra] diff --git a/content/inside-rust/compiler-team-meeting@2.md b/content/inside-rust/compiler-team-meeting@2.md index 7ad4f6591..b9b2567b6 100644 --- a/content/inside-rust/compiler-team-meeting@2.md +++ b/content/inside-rust/compiler-team-meeting@2.md @@ -14,7 +14,7 @@ The compiler team had our weekly triage meeting on 2019-10-24. You can find the [minutes](https://rust-lang.github.io/compiler-team/minutes/triage-meeting/2019-10-24/) on the [compiler-team](https://github.com/rust-lang/compiler-team) repository. Each week, we have general announcements from the team followed by check-ins from two fo the compiler team working groups. -## Announcments +## Announcements - [@simulacrum](https://github.com/Mark-Simulacrum) landed the rust-std split PR which decreases the size of the rustc-dev rustup component [#65474](https://github.com/rust-lang/rust/pull/65474) diff --git a/content/inside-rust/compiler-team-meeting@3.md b/content/inside-rust/compiler-team-meeting@3.md index 0b0fc3810..0c68a8941 100644 --- a/content/inside-rust/compiler-team-meeting@3.md +++ b/content/inside-rust/compiler-team-meeting@3.md @@ -16,7 +16,7 @@ Each week, we have general announcements from the team followed by check-ins fro # 2019-10-31 -## Announcments +## Announcements Rust 1.39 ships on Thursday! diff --git a/content/inside-rust/compiler-team-meeting@5.md b/content/inside-rust/compiler-team-meeting@5.md index a3f9674c7..38c2909bb 100644 --- a/content/inside-rust/compiler-team-meeting@5.md +++ b/content/inside-rust/compiler-team-meeting@5.md @@ -25,7 +25,7 @@ Each week, we have general announcements from the team followed by check-ins fro - [@cjgillot] replaced a lot of TypeFoldable impls with a derive [#66384](https://github.com/rust-lang/rust/pull/66384) - The Infra team has finished evaluating GitHub Actions and we're switching! - - This will have a signficant, positive impact on CI build time. + - This will have a significant, positive impact on CI build time. - [@centril] is fixing useless `` spans [#66364](https://github.com/rust-lang/rust/pull/66364) @@ -83,7 +83,7 @@ This week we heard from three working groups because we ran out of time in the p ### [wg-rls-2.0](https://rust-lang.github.io/compiler-team/working-groups/rls-2.0/) -- Work is procedding on splitting core of rust-analyzer into crates. +- Work is proceeding on splitting core of rust-analyzer into crates. - Find usages is implemented. diff --git a/content/inside-rust/compiler-team-meeting@6.md b/content/inside-rust/compiler-team-meeting@6.md index 3b6ac839f..e6b548900 100644 --- a/content/inside-rust/compiler-team-meeting@6.md +++ b/content/inside-rust/compiler-team-meeting@6.md @@ -41,7 +41,7 @@ Each week, we have general announcements from the team followed by check-ins fro ### [wg-self-profile] - The ["Minimum Viable Product"][sp_mvp] has been completed! - - Self-profling is enabled for all perf.rust-lang.org runs and we automatically publish the data. ([Example][sp_example]) + - Self-profiling is enabled for all perf.rust-lang.org runs and we automatically publish the data. ([Example][sp_example]) - [@mw] implemented query-key recording so queries can now be attributed to individual query invocations. diff --git a/content/inside-rust/core-team-update.md b/content/inside-rust/core-team-update.md index b497c7a12..3a002bc36 100644 --- a/content/inside-rust/core-team-update.md +++ b/content/inside-rust/core-team-update.md @@ -46,7 +46,7 @@ were spun up, shut down, and changed, we haven't always done a good job of making it clear where the boundaries of responsibility lie in each team. Part of the magic in Rust's governance structure is that individual teams are given significant authority to do as they see fit, but that also means that -we have to be concious about scope. We'll have more to report on this process +we have to be conscious about scope. We'll have more to report on this process as it continues to unfold, but the end goal is stated in the roadmap: > The Rust teams, in concert with the core team, will work to establish a @@ -74,7 +74,7 @@ on crates.io. We are conducting a full audit of these packages, making sure that they're things that should be owned by the project, making sure that they have appropriate permissions, making sure that they have people taking care of them, all of that kind of thing. Historically, we've been fairly ad-hoc about this sort -of thing, but as we grow, it is very imporant to be deliberate. An +of thing, but as we grow, it is very important to be deliberate. An [RFC][crate-ownership-rfc] was just opened to create a policy here. ## Thanks! diff --git a/content/inside-rust/ffi-unwind-design-meeting.md b/content/inside-rust/ffi-unwind-design-meeting.md index e663e0567..0b3af4eda 100644 --- a/content/inside-rust/ffi-unwind-design-meeting.md +++ b/content/inside-rust/ffi-unwind-design-meeting.md @@ -197,7 +197,7 @@ these instances of undefined behavior could be detected at runtime, but the code to do so would impose an undesirable code-size penalty, entirely negating the optimizations made possible by using `panic=unwind` or the non-unwinding `"C"` ABI. This code would therefore only be appropriate for debug builds. -Additionally, the complexity of implementing such checks may outweight their +Additionally, the complexity of implementing such checks may outweigh their benefits. Note that unwinding through a frame that has destructors without running those diff --git a/content/inside-rust/ffi-unwind-longjmp.md b/content/inside-rust/ffi-unwind-longjmp.md index d049ab0ab..356efe58e 100644 --- a/content/inside-rust/ffi-unwind-longjmp.md +++ b/content/inside-rust/ffi-unwind-longjmp.md @@ -25,7 +25,7 @@ unwind"`, so one option is to simply wind down the project group. While drafting the `"C unwind"` RFC, however, we discovered that the existing guarantees around `longjmp` and similar functions could be improved. Although this is not strictly related to unwinding[1](#longjmp-unwind), they -are closesly related: they are both "non-local" control-flow mechanisms that +are closely related: they are both "non-local" control-flow mechanisms that prevent functions from returning normally. Because one of the goals of the Rust project is for Rust to interoperate with existing C-like languages, and these control-flow mechanisms are widely used in practice, we believe that Rust must diff --git a/content/inside-rust/goverance-wg-cfp@1.md b/content/inside-rust/goverance-wg-cfp@1.md index e1fa6d5c1..064a63998 100644 --- a/content/inside-rust/goverance-wg-cfp@1.md +++ b/content/inside-rust/goverance-wg-cfp@1.md @@ -29,7 +29,7 @@ topic. To help do this we're going to extend our current meeting duration from The current goals are to documenting the de-facto governance structure, provide the result as a RFC and then if merged provide a version on -[forge.rust-lang.org](https://forge.rust-lang.org/) so that it has greater visbility. We also want to +[forge.rust-lang.org](https://forge.rust-lang.org/) so that it has greater visibility. We also want to schedule people involved in Rust and other governance structures to come and talk about their experiences. diff --git a/content/inside-rust/ide-future.md b/content/inside-rust/ide-future.md index a7d98a72d..d0c95a736 100644 --- a/content/inside-rust/ide-future.md +++ b/content/inside-rust/ide-future.md @@ -37,7 +37,7 @@ It is an unstable format which rustc uses to record information about the compil It contains a pretty high-level information. For example, for each identifier in the source-crate, save-analyzer will map this identifier to a definition and list of usages. `env RUSTFLAGS="-Zunstable-options -Zsave-analysis" cargo check` can be used to instruct `rustc` to produce save-analysis files (in JSON format). -Because save-analysis is produced directly from rustc iternal data structures, it is guaranteed to be correct (modulo bugs in rustc itself). +Because save-analysis is produced directly from rustc internal data structures, it is guaranteed to be correct (modulo bugs in rustc itself). # Query model @@ -59,5 +59,5 @@ If this approach works, we will consider freezing RLS and focusing fully on rust Long term, the plan is to unify the save-analysis fallback path and the lazy analysis. In parallel to this RLS/rust-analyzer unification effort, we continue to pursue rustc library-ification, with a specific focus on traits solving (via chalk) and type inference. -"Library-ification" is a term we've been using for the process of extracting code out of rustc into re-usable libaries which can be shared by both rustc and rust-analyzer. +"Library-ification" is a term we've been using for the process of extracting code out of rustc into re-usable libraries which can be shared by both rustc and rust-analyzer. The goal is to use library-ification to gradually reduce the amount of duplicated code between rustc and rust-analyzer, with the goal of eventually either having a single code-base, or having the vast majority of the logic be shared. diff --git a/content/inside-rust/infra-team-meeting@1.md b/content/inside-rust/infra-team-meeting@1.md index f13ac58ed..c973f85df 100644 --- a/content/inside-rust/infra-team-meeting@1.md +++ b/content/inside-rust/infra-team-meeting@1.md @@ -9,7 +9,7 @@ team = "the infrastructure team" team_url = "https://www.rust-lang.org/governance/teams/operations#infra" +++ -Meeting run by pietroalbini. Mintues written by pietroalbini. +Meeting run by pietroalbini. Minutes written by pietroalbini. Attending: aidanhs, alexcrichton, kennytm, Mark-Simulacrum, pietroalbini, shepmaster [Start of the conversation][discord] diff --git a/content/inside-rust/infra-team-meeting@5.md b/content/inside-rust/infra-team-meeting@5.md index b87bf68fa..e46f757db 100644 --- a/content/inside-rust/infra-team-meeting@5.md +++ b/content/inside-rust/infra-team-meeting@5.md @@ -26,7 +26,7 @@ Route53, but AWS only supports CNAMEs on the apex pointing to other AWS resources. Because of that, the crates.io DNS was managed on a different service until today, causing maintenance issues on our end. -The solution we’re working torwards is to put CloudFront in front of crates.io, +The solution we’re working towards is to put CloudFront in front of crates.io, and that will finally allow us to migrate the crates.io domain to AWS. pietroalbini is finishing the last infra touches, and we expect to deploy the changes in the coming days. diff --git a/content/inside-rust/intro-rustc-self-profile/index.md b/content/inside-rust/intro-rustc-self-profile/index.md index 20cc21588..7f8414362 100644 --- a/content/inside-rust/intro-rustc-self-profile/index.md +++ b/content/inside-rust/intro-rustc-self-profile/index.md @@ -50,7 +50,7 @@ $ rustup update nightly ## Profiling the compiler Now we can build it and tell `rustc` to profile the build of the `regex` crate. -This will cause three new files to be created in the working directory which contain the profling data. +This will cause three new files to be created in the working directory which contain the profiling data. ```sh $ cargo rustc -- -Zself-profile diff --git a/content/inside-rust/keeping-secure-with-cargo-audit-0.18.md b/content/inside-rust/keeping-secure-with-cargo-audit-0.18.md index 3a4e8d2da..7ce954ba2 100644 --- a/content/inside-rust/keeping-secure-with-cargo-audit-0.18.md +++ b/content/inside-rust/keeping-secure-with-cargo-audit-0.18.md @@ -10,7 +10,7 @@ team = "the Secure Code WG" team_url = "https://www.rust-lang.org/governance/wgs/wg-secure-code" +++ -[`cargo audit`](https://crates.io/crates/cargo-audit) checks your project's dependencies for known security vulnerabilites. +[`cargo audit`](https://crates.io/crates/cargo-audit) checks your project's dependencies for known security vulnerabilities. By default `cargo audit` checks on your `Cargo.lock` file, but it can also [scan compiled binaries](https://github.com/rustsec/rustsec/tree/main/cargo-audit#cargo-audit-bin-subcommand). You can install `cargo-audit` and run it against your project with the following commands: diff --git a/content/inside-rust/keyword-generics-progress-report-feb-2023.md b/content/inside-rust/keyword-generics-progress-report-feb-2023.md index 7a9938b02..63534eb2c 100644 --- a/content/inside-rust/keyword-generics-progress-report-feb-2023.md +++ b/content/inside-rust/keyword-generics-progress-report-feb-2023.md @@ -292,7 +292,7 @@ to be made available as well. As we alluded to earlier in the post: one of the biggest challenges we see in language design is adding features in a way that makes them feel like they're in harmony with the rest of the language - and not something which stands out as -noticably different. And because we're touching on something core to Rust, the +noticeably different. And because we're touching on something core to Rust, the way we do keywords, we have to pay extra close attention here to make sure Rust keeps feeling like a single language. diff --git a/content/inside-rust/keyword-generics.md b/content/inside-rust/keyword-generics.md index 6b2bbbe6b..24b27a0f1 100644 --- a/content/inside-rust/keyword-generics.md +++ b/content/inside-rust/keyword-generics.md @@ -124,8 +124,8 @@ trait Const { } /// `42` as a "const" (type) generic: -struct FourtyTwo; -impl Const for FourtyTwo { +struct FortyTwo; +impl Const for FortyTwo { const VAL: i32 = 42; } @@ -135,7 +135,7 @@ impl> Const for AddOne { const VAL: i32 = C::VAL + 1; } -AddOne::::VAL +AddOne::::VAL ``` Today this is as easy as writing a `const fn`: @@ -312,7 +312,7 @@ Choosing between sync or async code is a fundamental choice which needs to be made. This is complexity which cannot be avoided, and which needs to exist somewhere. Currently in Rust that complexity is thrust entirely on users of Rust, making them responsible for choosing whether their code should support -async Rust or not. But other languages have made diferent choices. For example +async Rust or not. But other languages have made different choices. For example Go doesn't distinguish between "sync" and "async" code, and has a runtime which is able to remove that distinction. diff --git a/content/inside-rust/lang-roadmap-2024.md b/content/inside-rust/lang-roadmap-2024.md index 708478205..b60e5693a 100644 --- a/content/inside-rust/lang-roadmap-2024.md +++ b/content/inside-rust/lang-roadmap-2024.md @@ -86,7 +86,7 @@ you learn how the Rust borrow checker works, there remain a lot of "small details" that you have to get just right to get your Rust program to compile. For Rust 2024, we will identify and eliminate many of those patterns and -idiosyncracies that one must learn to use Rust; our goal is to let you focus +idiosyncrasies that one must learn to use Rust; our goal is to let you focus squarely on the "inherent complexity" of your problem domain and avoid "accidental complexity" from Rust as much as possible. diff --git a/content/inside-rust/lang-team-mar-update@0.md b/content/inside-rust/lang-team-mar-update@0.md index 6c9cb69b5..206438c22 100644 --- a/content/inside-rust/lang-team-mar-update@0.md +++ b/content/inside-rust/lang-team-mar-update@0.md @@ -37,7 +37,7 @@ Did you know that you can see the lang team's active projects on our [project bo * min const generics will be stable in 1.51 * we are looking at various small extensions * there is now a weekly meeting to look into improvements -* declarative macro repitition counts: +* declarative macro repetition counts: * there is an [open RFC](https://github.com/rust-lang/rfcs/pull/3086) with proposed FCP * instruction set attribute: * exploration continues, the interaction of instruction set attribute with inline is not great, but it's not clear how to improve diff --git a/content/inside-rust/leadership-council-update@0.md b/content/inside-rust/leadership-council-update@0.md index 50f0f4c46..eeca8b71f 100644 --- a/content/inside-rust/leadership-council-update@0.md +++ b/content/inside-rust/leadership-council-update@0.md @@ -35,7 +35,7 @@ And we've been discussing all of this work in the [public council stream on Zuli We have a lot of ideas on problems of the Rust Project we _could_ work on, but we know we, as a council, can only realistically make progress on a few topics at the same time. -We've come up with a proposed list of our first three priorities, and we'd like the project's feedback on whether this matches your expectations. This is a starting place for iterative improvement over time; we're planning on re-evaluating whether these priorties are still the right ones about every two months or so. +We've come up with a proposed list of our first three priorities, and we'd like the project's feedback on whether this matches your expectations. This is a starting place for iterative improvement over time; we're planning on re-evaluating whether these priorities are still the right ones about every two months or so. The type of feedback we're most interested in is hearing about topics or issues you think are more important or urgent than one or more of the following three priorities, and why we should tackle that topic instead of what we have listed here. If this list sounds good to you, we'd like to hear that as well! diff --git a/content/inside-rust/survey-2021-report.md b/content/inside-rust/survey-2021-report.md index ee73646a9..6e9dfad08 100644 --- a/content/inside-rust/survey-2021-report.md +++ b/content/inside-rust/survey-2021-report.md @@ -15,7 +15,7 @@ make the complete (-ish) dataset available. We have compiled a report which cont all questions with minimal analysis. We have elided a few sensitive questions and have combined some answers or elided some answers where there is any chance of respondents being identified or of sensitive data being released. -We intend to produce further small reports with more analysis targetted at specific teams or groups within the +We intend to produce further small reports with more analysis targeted at specific teams or groups within the project. If there is any analysis or processed data you'd like to see, please get in touch with the survey working group via [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/294169-t-community.2Frust-survey-2021). diff --git a/content/inside-rust/test-infra-oct-2024.md b/content/inside-rust/test-infra-oct-2024.md index bf0acea84..d20087559 100644 --- a/content/inside-rust/test-infra-oct-2024.md +++ b/content/inside-rust/test-infra-oct-2024.md @@ -20,7 +20,7 @@ supporting components in our build system [bootstrap]. This test infra is used mainly by rustc and rustdoc. Other tools like cargo, miri or rustfmt maintain their own test infra. -As usual, if you encounter bugs or UX issues when using our test infrastrucutre, +As usual, if you encounter bugs or UX issues when using our test infrastructure, please [file an issue][new-issue]. Bugs and papercuts can't be fixed if we don't know about them! diff --git a/content/inside-rust/this-development-cycle-in-cargo-1.78/index.md b/content/inside-rust/this-development-cycle-in-cargo-1.78/index.md index e4c327656..3770f2aee 100644 --- a/content/inside-rust/this-development-cycle-in-cargo-1.78/index.md +++ b/content/inside-rust/this-development-cycle-in-cargo-1.78/index.md @@ -69,7 +69,7 @@ to render ANSI escape codes as styles in an SVG (credit goes to [`term-transcript` for the original idea](https://crates.io/crates/term-transcript)) and integrated that into snapbox ([trycmd#256](https://github.com/assert-rs/trycmd/pull/256)) -which we use for snapshoting our UI tests. +which we use for snapshotting our UI tests. ![rendering of cargo-add's output using SVG](stderr.term.svg) *(not a screenshot but generated from cargo's output)* diff --git a/content/inside-rust/this-development-cycle-in-cargo-1.80.md b/content/inside-rust/this-development-cycle-in-cargo-1.80.md index 86d49c3da..5bca1f9ea 100644 --- a/content/inside-rust/this-development-cycle-in-cargo-1.80.md +++ b/content/inside-rust/this-development-cycle-in-cargo-1.80.md @@ -203,7 +203,7 @@ For the rest, we are talking about the following modes: | mode | MSRV | yanked | prerelease | |--------------------------------------|----------|----------|----------| | this is yet another candidate | Required | Never? | Never? | -| de-priorize this over other versions | Required | Likely | Likely | +| de-prioritize this over other versions | Required | Likely | Likely | | don't resolve to if already in use | Likely | Required | Required | This helped to show that we probably want to name the field `incompatible-rust-version` to clarify that we are talking about how we are handling those packages and to leave room for `resolver.rust-version` to override what version is used when resolving dependencies. diff --git a/content/inside-rust/traits-sprint-1.md b/content/inside-rust/traits-sprint-1.md index 3da370558..041d90b4a 100644 --- a/content/inside-rust/traits-sprint-1.md +++ b/content/inside-rust/traits-sprint-1.md @@ -24,13 +24,13 @@ The overarching goal of the [traits working group][wg-traits] is to create a per [wg-traits]: https://rust-lang.github.io/wg-traits/ -As if that weren't enough, we'd like the implementaton to be **reusable**, too -- meaning that it can be used by rustc, yes, but also rust-analyzer and potentially other contexts as well. +As if that weren't enough, we'd like the implementation to be **reusable**, too -- meaning that it can be used by rustc, yes, but also rust-analyzer and potentially other contexts as well. This effort is part of one of the big, longer term goals for the compiler team: **library-ification**. This refers to the idea of breaking apart the compiler into independent libraries that can be learned, tested, and developed independently. In order to achieve these and future features, our work is split into two parts: 1) Improving rustc's existing trait solver. 2) Design and implement the [Chalk] trait solver, work towards integration into rustc. The Chalk trait solver, briefly, is a logic-based trait solver, designed to be independent of rustc internals. In addition to it being more powerful than the current rustc trait solving implementation, Chalk can be used as a library for compiler-related work, such as IDE integration (e.g. [rust-analyzer](https://github.com/rust-analyzer/rust-analyzer)). -Coming into 2020, we — the traits working group — knew we wanted to get more organized and start to push more on getting Chalk fully integrated into rustc, by cleaning up the Chalk codebase itself, fixing bugs, implementing new features, and ultimately integrating Chalk into rustc itself. In addition, we are committed to documenting design considerations and decisions for better accesibility now and in the future. For example, we now publish a Chalk [book] which, while incomplete, attempts to document the Chalk internals somewhat akin to the [rustc dev guide](https://rustc-dev-guide.rust-lang.org/). +Coming into 2020, we — the traits working group — knew we wanted to get more organized and start to push more on getting Chalk fully integrated into rustc, by cleaning up the Chalk codebase itself, fixing bugs, implementing new features, and ultimately integrating Chalk into rustc itself. In addition, we are committed to documenting design considerations and decisions for better accessibility now and in the future. For example, we now publish a Chalk [book] which, while incomplete, attempts to document the Chalk internals somewhat akin to the [rustc dev guide](https://rustc-dev-guide.rust-lang.org/). #### A note about Chalk integration in rustc An experimental integration of Chalk was in rustc (under the `-Z chalk` flag) for over a year, but since its initial implementation, little work had been done while much work had been done on Chalk itself. This ultimately meant that the initial implementation based on the older Chalk version looks very different from what an implementation based on the current Chalk would and should look like. Under this reasoning, that experimental implementation has been removed. @@ -156,7 +156,7 @@ We expect to land basic support for `impl Trait` fairly early in the next sprint ### Exploratory implementations and research In addition to the more concrete goals, there is also some exploratory work being done: -* [Implementating a recursive solver][chalk#351] +* [Implementing a recursive solver][chalk#351] * [Converting semantic to syntactic equality][chalk#364] * [Outputting a file for reproducing bugs][chalk#365] @@ -166,7 +166,7 @@ In addition to the more concrete goals, there is also some exploratory work bein ### Chalk performance work -Most of the work on Chalk has been focused on design, and *not much* has been done to optimize performance. While the particular "end goal" isn't clear here, we hope to start by createing a set of memory, cpu, and time benchmarks for Chalk. With this framework, we can diagnose specific performance issues and monitor future changes for regressions. Part of this will be to [land][chalk#337] `tracing` support. +Most of the work on Chalk has been focused on design, and *not much* has been done to optimize performance. While the particular "end goal" isn't clear here, we hope to start by creating a set of memory, cpu, and time benchmarks for Chalk. With this framework, we can diagnose specific performance issues and monitor future changes for regressions. Part of this will be to [land][chalk#337] `tracing` support. [chalk#337]: https://github.com/rust-lang/chalk/issues/337 diff --git a/content/inside-rust/traits-sprint-2.md b/content/inside-rust/traits-sprint-2.md index 08f617451..08ab54e82 100644 --- a/content/inside-rust/traits-sprint-2.md +++ b/content/inside-rust/traits-sprint-2.md @@ -84,17 +84,17 @@ We landed initial support for `impl Trait` during this sprint. It doesn't yet su ### Progress towards removing the leak check in rustc -In the rustc trait solver, there is currently a special check done in regards to lifetimes called the "leak check". Without going into the techinical details, there are some design flaws with this approach and it being there blocks features such lazy normalization (which is required for features such const generics and GATs). However, removing the leak check completely has some backward-compatiblity concerns. But [some progress] was made. +In the rustc trait solver, there is currently a special check done in regards to lifetimes called the "leak check". Without going into the technical details, there are some design flaws with this approach and it being there blocks features such lazy normalization (which is required for features such const generics and GATs). However, removing the leak check completely has some backward-compatibility concerns. But [some progress] was made. ### Adding a recursive solver to Chalk When Chalk was first written, it used a stateful recursive solver. It was then changed to use a prolog-solving approach called SLG. SLG uses a more stateless approach where answers to subgoals can be reused. -While SLG is more complete, there are some design tradeoffs. One example in particular is related to how we handle associated types. It's completely possible that we can and will resolve these design problems in the future. In the meantime, however, we ressurected the old recursive solver. [Rust-analyzer] has switched to using it and results have been positive. +While SLG is more complete, there are some design tradeoffs. One example in particular is related to how we handle associated types. It's completely possible that we can and will resolve these design problems in the future. In the meantime, however, we resurrected the old recursive solver. [Rust-analyzer] has switched to using it and results have been positive. For now, we'll continue to work on resolving design problems with the SLG solver. Eventually, we expect that we'll evaluate the two and pick one to stick with. -### Creating reproducable Chalk test files +### Creating reproducible Chalk test files Oftentimes we'll get a bug report where Chalk doesn't report the result one would expect. And as anyone who has maintained a piece of software knows, getting a minimal reproduction is difficult. What makes it even more difficult is that the goals and programs that Chalk understands are a "lowered" form of actual Rust code, which means not only do we have to make a minimal *Rust* example, but also a minimal *Chalk* example. diff --git a/content/inside-rust/traits-sprint-3.md b/content/inside-rust/traits-sprint-3.md index bd85dbe0f..21ac41c64 100644 --- a/content/inside-rust/traits-sprint-3.md +++ b/content/inside-rust/traits-sprint-3.md @@ -77,7 +77,7 @@ As a long term goal, we hope to one day have a shared type library between Chalk ### Writing a `.chalk` file for debugging -As part of Chalk tests, we can write Rust-like "programs" that get parsed into Chalk types. Importantly, these programs are much more succint than the types they get lowered to. As part of an effort to better enable debugging, we implemented a system to go in the opposite direction: to be able to generate the Rust-like programs from the underlying types. This is extremely useful to, for example, debug a bug for a given bit of code that rustc tries to compile. Additionally, this could be used to generate programs for cases with performance problems. +As part of Chalk tests, we can write Rust-like "programs" that get parsed into Chalk types. Importantly, these programs are much more succinct than the types they get lowered to. As part of an effort to better enable debugging, we implemented a system to go in the opposite direction: to be able to generate the Rust-like programs from the underlying types. This is extremely useful to, for example, debug a bug for a given bit of code that rustc tries to compile. Additionally, this could be used to generate programs for cases with performance problems. ### Improving `impl Trait` support diff --git a/content/inside-rust/update-on-the-github-actions-evaluation.md b/content/inside-rust/update-on-the-github-actions-evaluation.md index 24264963f..96daffb43 100644 --- a/content/inside-rust/update-on-the-github-actions-evaluation.md +++ b/content/inside-rust/update-on-the-github-actions-evaluation.md @@ -36,7 +36,7 @@ to a dedicated pool of 8-core VMs GitHub generously prepared for us. Another technical change is that we’re now running most CI builds on the [rust-lang-ci/rust] fork. This should only impact team members that want to get -a list of all the past builds, and should be completly transparent to everyone +a list of all the past builds, and should be completely transparent to everyone else thanks to our integration bot [@bors]. ## What configuration is the project using? diff --git a/content/new-years-rust-a-call-for-community-blogposts.md b/content/new-years-rust-a-call-for-community-blogposts.md index 305cb46e7..c61cb9ed0 100644 --- a/content/new-years-rust-a-call-for-community-blogposts.md +++ b/content/new-years-rust-a-call-for-community-blogposts.md @@ -20,7 +20,7 @@ for ideas of what the goals should be. As open source software becomes more and more ubiquitous and popular, the Rust team is interested in exploring new and innovative ways to solicit community feedback and -participation. We're commited to extending and improving our community organization and +participation. We're committed to extending and improving our community organization and outreach- and this effort is just the first of what we hope to be many iterations of new kinds of community feedback mechanisms. diff --git a/content/parallel-rustc/index.md b/content/parallel-rustc/index.md index e0105c147..277de191d 100644 --- a/content/parallel-rustc/index.md +++ b/content/parallel-rustc/index.md @@ -153,7 +153,7 @@ to schedule them? Fortunately no. The compiler uses the [jobserver protocol](https://www.gnu.org/software/make/manual/html_node/POSIX-Jobserver.html) to limit the number of threads it creates. If a lot of interprocess parallelism -is occuring, intraprocess parallelism will be limited appropriately, and +is occurring, intraprocess parallelism will be limited appropriately, and the number of threads will not exceed the number of cores. ## How to use it diff --git a/content/reducing-support-for-32-bit-apple-targets.md b/content/reducing-support-for-32-bit-apple-targets.md index 25f410e04..076391982 100644 --- a/content/reducing-support-for-32-bit-apple-targets.md +++ b/content/reducing-support-for-32-bit-apple-targets.md @@ -88,7 +88,7 @@ foreseeable future (as we do with all the releases shipped so far). The code implementing the targets won’t be removed from the compiler codebase, so you’ll also be able to build future releases from source on your own (keeping in mind they might have bugs or be broken, as that code will be -completly untested). +completely untested). # What about the nightly channel? diff --git a/content/rust-at-two-years/index.md b/content/rust-at-two-years/index.md index f23a880cc..36b436db4 100644 --- a/content/rust-at-two-years/index.md +++ b/content/rust-at-two-years/index.md @@ -366,7 +366,7 @@ day before RustConf in Portland! The Mozilla Rust folks are going to have [Outreachy] and [GSoC] interns this summer working on a variety of projects. -We've also had success involving contributors when there are low-committment, +We've also had success involving contributors when there are low-commitment, high impact tasks to be done. One of those efforts was [improving the format of error messages]-- check out the [82 participants on this issue]! The Libz Blitz mentioned in a previous section is set up specifically to be another source of diff --git a/content/rustup.md b/content/rustup.md index d3bbef213..6e4af08c8 100644 --- a/content/rustup.md +++ b/content/rustup.md @@ -504,7 +504,7 @@ to run *C++* code on the web by converting LLVM IR to JavaScript (or the asm.js subset of JavaScript). And the upcoming [WebAssembly][] (wasm) standard will cement the web platform as a first-class target for programming languages. -*Rust is uniquely-positioned to be the most powerful and usable wasm-targetting +*Rust is uniquely-positioned to be the most powerful and usable wasm-targeting language for the immediate future.* The same properties that make Rust so portable to real hardware makes it nearly trivial to port Rust to wasm. The same can't be said for languages with complex runtimes that include garbage diff --git a/crates/generate_blog/src/main.rs b/crates/generate_blog/src/main.rs index 8063c061c..aff450738 100644 --- a/crates/generate_blog/src/main.rs +++ b/crates/generate_blog/src/main.rs @@ -75,7 +75,7 @@ fn main() -> Result<(), Box> { let (team, team_url) = 'team_prompt: { if release { - // For official release annoucement posts, the whole + // For official release announcement posts, the whole // "Rust Release Team" is usually the author. break 'team_prompt (None, None); } @@ -140,7 +140,7 @@ fn main() -> Result<(), Box> { .with_help_message( " To include images in a post, the post will be stored in /index.md, - instead of the usualy .md. Images can then be stored in the directory + instead of the usually .md. Images can then be stored in the directory / right next to the post itself. They can be included with a relative link, e.g. ![alt text](my_impage.png). ", diff --git a/templates/latest.html b/templates/latest.html index ac88f7882..5f7dce0a6 100644 --- a/templates/latest.html +++ b/templates/latest.html @@ -4,5 +4,5 @@ Redirect -

Click here to be redirected to the latest Rust release annoucement.

+

Click here to be redirected to the latest Rust release announcement.

{% break %}{% endif %}{% endfor -%} diff --git a/templates/releases.html b/templates/releases.html index 600948858..eedc5495e 100644 --- a/templates/releases.html +++ b/templates/releases.html @@ -6,7 +6,7 @@

This is a subset of the main Rust blog - listing only official release annoucement posts. + listing only official release announcement posts.

Did you know? There are convenient redirects for