-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 11 pull requests #125989
Rollup of 11 pull requests #125989
Conversation
To reduce indentation and improve readability.
We still check for the `rental`/`allsorts-rental` crates. But now if they are detected we just emit a fatal error, instead of emitting a warning and providing alternative behaviour. The original "hack" implementing alternative behaviour was added in rust-lang#73345. The lint was added in rust-lang#83127. The tracking issue is rust-lang#83125. The direct motivation for the change is that providing the alternative behaviour is interfering with rust-lang#125174 and follow-on work.
This example is spiritually an example of LazyLock, as it computes a variable at runtime but accepts no inputs into that process. It is also slightly simpler and thus easier to understand. Change it to an even-more concise version and move it to LazyLock. The example now editorializes slightly more. This may be unnecessary, but it can be educational for the reader.
While slightly verbose, it helps explain "why bother with OnceLock?" This is a point of confusion that has been raised multiple times shortly before and after the stabilization of LazyLock.
This is needed for fixing the missing license issue. See rust-lang#125465.
The flag propagates cargo configs to `rustc-perf --cargo-config`, which is particularly useful when the environment is air-gapped, and you want to use the default set of training crates vendored in the rustc-src tarball.
The addition of `core::iter::zip` (rust-lang#82917) set a precedent for adding plain functions for iterator adaptors. Adding `chain` makes it a little easier to `chain` two iterators. ``` for (x, y) in chain(xs, ys) {} // vs. for (x, y) in xs.into_iter().chain(ys) {} ```
This was an ancient regression test for rust-lang#12685, caused by `-Zunpretty=expanded` crashing on certain code produced by `#[derive(RustcEncodable)]`.
…nieu Add function `core::iter::chain` The addition of `core::iter::zip` (rust-lang#82917) set a precedent for adding plain functions for iterator adaptors. Adding `chain` makes it a little easier to `chain` two iterators. ```rust for (x, y) in chain(xs, ys) {} // vs. for (x, y) in xs.into_iter().chain(ys) {} ``` There is prior art for the utility of this in [`itertools::chain`](https://docs.rs/itertools/latest/itertools/fn.chain.html). Approved ACP rust-lang/libs-team#154
…stebank Convert `proc_macro_back_compat` lint to an unconditional error. We still check for the `rental`/`allsorts-rental` crates. But now if they are detected we just emit a fatal error, instead of emitting a warning and providing alternative behaviour. The original "hack" implementing alternative behaviour was added in rust-lang#73345. The lint was added in rust-lang#83127. The tracking issue is rust-lang#83125. The direct motivation for the change is that providing the alternative behaviour is interfering with rust-lang#125174 and follow-on work. r? ``@estebank``
…-are-lazy, r=Nilstrieb Explain differences between `{Once,Lazy}{Cell,Lock}` types The question of "which once-ish cell-ish type should I use?" has been raised multiple times, and is especially important now that we have stabilized the `LazyCell` and `LazyLock` types. The answer for the `Lazy*` types is that you would be better off using them if you want to use what is by far the most common pattern: initialize it with a single nullary function that you would call at every `get_or_init` site. For everything else there's the `Once*` types. "For everything else" is a somewhat weak motivation, as it only describes by negation. While contrasting them is inevitable, I feel positive motivations are more understandable. For this, I now offer a distinct example that helps explain why `OnceLock` can be useful, despite `LazyLock` existing: you can do some cool stuff with it that `LazyLock` simply can't support due to its mere definition. The pair of `std::sync::*Lock`s are usable inside a `static`, and can serve roles in async or multithreaded (or asynchronously multithreaded) programs that `*Cell`s cannot. Because of this, they received most of my attention. Fixes rust-lang#124696 Fixes rust-lang#125615
…jieyouxu Create `run-make` `env_var` and `env_var_os` helpers As mentioned in rust-lang#125886. It's quite useful to know which environment variable failed, so better provide a helper helping with that. r? `@jieyouxu`
…pietroalbini Ignore `vec_deque_alloc_error::test_shrink_to_unwind` test on non-unwind targets rust-lang#123803 added this test which requires unwinding to succeed. This conditionally ignores the test on non-unwind targets (as is the case with other tests using `catch_unwind`).
…onfig, r=Kobzol feat(opt-dist): new flag `--benchmark-cargo-config` This should be the last piece toward self-contained `opt-dist` (I believe). The flag propagates cargo configs to `rustc-perf --cargo-config`, which is particularly useful when the environment is air-gapped, and you want to use the default set of training crates vendored in the rustc-src tarball. It fixes the issue described in rust-lang#125465 > * The current pinned rustc-perf uses `tempfile::Tempdir` as the working directory when collecting profiles from some of these packages. This "tmp" working directory usage make it impossible for Cargo to pick up the correct vendor sources setting in `.cargo/config.toml` bundled in the rustc-src tarball. [^1] > [^1]: https://github.com/rust-lang/rustc-perf/blob/4f313add609f43e928e98132358e8426ed3969ae/collector/src/compile/benchmark/mod.rs#L164-L173 See also * <rust-lang/rustc-perf#1913> * <rust-lang#125465> * https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/tempfile.20in.20rustc-perf.20make.20it.20hard.20to.20configure.20vendor r? Kobzol
Fix typo in the docs of `HashMap::raw_entry_mut` <!-- If this PR is related to an unstable feature or an otherwise tracked effort, please link to the relevant tracking issue here. If you don't know of a related tracking issue or there are none, feel free to ignore this. This PR will get automatically assigned to a reviewer. In case you would like a specific user to review your work, you can assign it to them by using r? <reviewer name> -->
Update books ## rust-lang/book 6 commits in 85442a608426d3667f1c9458ad457b241a36b569..5228bfac8267ad24659a81b92ec5417976b5edbc 2024-05-29 20:55:49 UTC to 2024-05-27 17:22:03 UTC - Fix typo in ch10-03 (rust-lang/book#3539) - Backport changes to ch 9 and 10 (rust-lang/book#3946) - infra: correctly support preprocessors for nostarch (rust-lang/book#3944) - Use `<kbd>` instead of `<span class="keystroke">` (rust-lang/book#3945) - infra: Fix clippy warning in remove_markup (rust-lang/book#3943) - fix: ch10-03 - misleading use of expect on .split (rust-lang/book#3939) ## rust-lang/edition-guide 2 commits in 0c68e90acaae5a611f8f5098a3c2980de9845ab2..bbaabbe088e21a81a0d9ae6757705020d5d7b416 2024-05-24 19:07:18 UTC to 2024-05-21 22:40:52 UTC - 2024: Document reserving `gen` keyword (rust-lang/edition-guide#300) - 2024: Document cargo changes (rust-lang/edition-guide#301) ## rust-embedded/book 1 commits in dd962bb82865a5284f2404e5234f1e3222b9c022..b10c6acaf0f43481f6600e95d4b5013446e29f7a 2024-05-31 08:51:50 UTC to 2024-05-31 08:51:50 UTC - Add some explanations as to why exception re-entrancy may still be an issue in a multicore-environment. (rust-embedded/book#367) ## rust-lang/reference 6 commits in e356977fceaa8591c762312d8d446769166d4b3e..6019b76f5b28938565b251bbba0bf5cc5c43d863 2024-06-03 15:58:57 UTC to 2024-05-25 18:35:54 UTC - Add Apple `target_abi` values to the example values (rust-lang/reference#1507) - this needs a space (rust-lang/reference#1506) - Mention Variadics With No Fixed Parameter (rust-lang/reference#1494) - Add "scopes" chapter. (rust-lang/reference#1040) - update patterns.md for const pattern RFC (rust-lang/reference#1456) - document guarantee about evaluation of associated consts and const blocks (rust-lang/reference#1497) ## rust-lang/rust-by-example 3 commits in 20482893d1a502df72f76762c97aed88854cdf81..4840dca06cadf48b305d3ce0aeafde7f80933f80 2024-05-28 13:56:12 UTC to 2024-05-27 11:51:10 UTC - Update mdbook-i18n-helpers to 0.3.3 (rust-lang/rust-by-example#1857) - Fix CI failure (rust-lang/rust-by-example#1856) - Add precision on From/Into asymmetry to from_into.md (rust-lang/rust-by-example#1855) ## rust-lang/rustc-dev-guide 4 commits in b6d4a49..6a7374b 2024-05-31 00:27:28 UTC to 2024-05-21 09:56:12 UTC - Flesh out the "representing types" chapter (rust-lang/rustc-dev-guide#1985) - sync the stage0 filename (rust-lang/rustc-dev-guide#1979) - Add Rust for Linux notification group entry (rust-lang/rustc-dev-guide#1984) - fix some typos (rust-lang/rustc-dev-guide#1983)
Update fuchsia maintainers This makes the maintainers list in the docs line up with the current [fuchsia team](https://github.com/rust-lang/team/blob/master/teams/fuchsia.toml).
…mease Include trailing commas in wrapped function declarations [RustDoc] Fixes rust-lang#125901.
Remove `tests/run-make-fulldeps/pretty-expanded` This was an ancient regression test for rust-lang#12685, caused by `-Zunpretty=expanded` crashing on certain code produced by `#[derive(RustcEncodable)]`. Given that this test predates `//@ pretty-expanded` tests, and was tied to ancient implementation details of the pretty-printer and `#[derive(RustcEncodable)]` (which the test no longer even uses), I think we can safely delete it. --- Spotted via rust-lang#125948.
@bors r+ p=5 rollup=never |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 23e040adec In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (a330e49): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (primary 0.7%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary 0.7%, secondary 3.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 667.724s -> 667.402s (-0.05%) |
Successful merges:
core::iter::chain
#106186 (Add functioncore::iter::chain
)proc_macro_back_compat
lint to an unconditional error. #125596 (Convertproc_macro_back_compat
lint to an unconditional error.){Once,Lazy}{Cell,Lock}
types #125696 (Explain differences between{Once,Lazy}{Cell,Lock}
types)run-make
env_var
andenv_var_os
helpers #125917 (Createrun-make
env_var
andenv_var_os
helpers)vec_deque_alloc_error::test_shrink_to_unwind
test on non-unwind targets #125927 (Ignorevec_deque_alloc_error::test_shrink_to_unwind
test on non-unwind targets)--benchmark-cargo-config
#125930 (feat(opt-dist): new flag--benchmark-cargo-config
)HashMap::raw_entry_mut
#125932 (Fix typo in the docs ofHashMap::raw_entry_mut
)tests/run-make-fulldeps/pretty-expanded
#125973 (Removetests/run-make-fulldeps/pretty-expanded
)Failed merges:
rustc_parse
top-level cleanups #125815 (rustc_parse
top-level cleanups)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup