Rollup of 9 pull requests #146662
Closed
Rollup of 9 pull requests #146662
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Travis Cross <[email protected]>
``` error: unexpected `...` --> $DIR/varargs-in-closure-isnt-supported.rs:5:20 | LL | let mut lol = |...| (); | ^^^ not a valid pattern | = note: C-variadic type `...` is not allowed here ```
All of the tier 3 targets in the list now link dynamically by default (except mips64el-unknown-linux-muslabi64, I overlooked that one). Adjust the list of targets expected to link statically accordingly. Signed-off-by: Jens Reidel <[email protected]>
When writing something like the expression `|_: ...| {}`, we now detect the `...` during parsing explicitly instead of relying on the detection in `parse_ty_common` so that we don't talk about "nested `...` are not supported".
```
error: unexpected `...`
--> $DIR/no-closure.rs:6:35
|
LL | const F: extern "C" fn(...) = |_: ...| {};
| ^^^
|
= note: only `extern "C"` and `extern "C-unwind"` functions may have a C variable argument list
```
update Readme add info about githooks and bootstrap.toml add info about config and remove linting specific files add link to rustc-dev-guide
…ze, r=jhpratt Stabilize `btree_entry_insert` feature This stabilises `btree_map::VacantEntry::insert_entry` and `btree_map::Entry::insert_entry`, following the FCP in [tracking issue](rust-lang#65225). New stable API: ```rust impl<'a, K: Ord, V, A: Allocator + Clone> Entry<'a, K, V, A> { pub fn insert_entry(self, value: V) -> OccupiedEntry<'a, K, V, A>; } impl<'a, K: Ord, V, A: Allocator + Clone> VacantEntry<'a, K, V, A> { pub fn insert_entry(mut self, value: V) -> OccupiedEntry<'a, K, V, A>; } ``` (FCP ended almost a year ago, so if it's needed for process we could rerun it) Closes: rust-lang#65225
…rop, r=lcnr remove FIXME block from `has_significant_drop`, it never encounters inference variables The `FIXME` block in `Ty::has_significant_drop` is outdated as related queries can now handle type inference. https://github.com/rust-lang/rust/blob/321a89bec57b8ca723d1af8f784490b950458c6a/compiler/rustc_middle/src/ty/util.rs#L1378-L1389 Closes rust-lang#86868 (other places mentioned in the issue have been resolved, or moved to other issues) r? types
…jackh726,traviscross don't apply temporary lifetime extension rules to non-extended `super let` Reference PR: rust-lang/reference#1980 This changes the semantics for `super let` (and macros implemented in terms of it, such as `pin!`, `format_args!`, `write!`, and `println!`) as suggested by `@theemathas` in rust-lang#145784 (comment), making `super let` initializers only count as [extending expressions](https://doc.rust-lang.org/nightly/reference/destructors.html#extending-based-on-expressions) when the `super let` itself is within an extending block. Since `super let` initializers aren't temporary drop scopes, their temporaries outside of inner temporary scopes are effectively always extended, even when not in extending positions; this only affects two cases as far as I can tell: - Block tail expressions in Rust 2024. This PR makes `f(pin!({ &temp() }))` drop `temp()` at the end of the block in Rust 2024, whereas previously it would live until after the call to `f` because syntactically the `temp()` was in an extending position as a result of `super let` in `pin!`'s expansion. - `super let` nested within a non-extended `super let` is no longer extended. i.e. a normal `let` is required to treat `super let`s as extending (in which case nested `super let`s will also be extending). Closes rust-lang#145784 This is a breaking change. Both static and dynamic semantics are affected. The most likely breakage is for programs to stop compiling, but it's technically possible for drop order to silently change as well (as in rust-lang#145784). Since this affects stable macros, it probably would need a crater run. Nominating for discussion alongside rust-lang#145784: `@rustbot` label +I-lang-nominated +I-libs-api-nominated Tracking issue for `super let`: rust-lang#139076
Suggest removing Box::new instead of unboxing it
Iterator repeat: no infinite loop for `last` and `count` This removes two cases of infinite looping from [`Repeat`](https://doc.rust-lang.org/nightly/std/iter/struct.Repeat.html): - [`last`](https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.last): By viewing the iterator as returning None after [omega](https://en.wikipedia.org/wiki/Ordinal_number) calls to `next`, this method can simply return the repeated element. - [`count`](https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.count): From its docs: """The method does no guarding against overflows, so counting elements of an iterator with more than [usize::MAX](https://doc.rust-lang.org/nightly/std/primitive.usize.html#associatedconstant.MAX) elements either produces the wrong result or panics. If overflow checks are enabled, a panic is guaranteed.""", so a panic'ing impl is allowed by the docs, and is more honest than an infinite loop.
Add tidy readme This PR adds a Readme to `src/tools/tidy`. Basically just explains how `tidy` works and covers all of tidy's checks, directives, and how to use tidy. I tried to add a bit more detail on some of the options like `--extra-checks` and the style directives that aren't really documented well elsewhere. Planning to link to this in the dev guide. Closes: rust-lang#129368
Detect attempt to use var-args in closure
```
error: unexpected `...`
--> $DIR/no-closure.rs:11:14
|
LL | let f = |...| {};
| ^^^ not a valid pattern
|
= note: only `extern "C"` and `extern "C-unwind"` functions may have a C variable argument list
error: unexpected `...`
--> $DIR/no-closure.rs:16:17
|
LL | let f = |_: ...| {};
| ^^^
|
= note: only `extern "C"` and `extern "C-unwind"` functions may have a C variable argument list
```
Fix rust-lang#146489, when trying to use c-style var-args in a closure. We emit a more targeted message. We also silence inference errors when the pattern is `PatKind::Err`.
…t, r=jieyouxu tests/run-make: Update list of statically linked musl targets All of the tier 3 targets in the list now link dynamically by default (except `mips64el-unknown-linux-muslabi64`, I apparently overlooked that one in my PR that changed this). Adjust the list of targets expected to link statically accordingly. See also rust-lang#144410, which changed these targets. Target by target: - `mips64-unknown-linux-musl`: this target does not exist AFAICT - `mips64-unknown-linux-muslabi64`: updated in the linked PR - `powerpc-unknown-linux-musl`: updated in the linked PR - `powerpc-unknown-linux-muslspe`: updated in the linked PR - `powerpc64-unknown-linux-musl`: updated in the linked PR - `riscv32gc-unknown-linux-musl`: updated in the linked PR - `s390x-unknown-linux-musl`: updated in the linked PR - `thumbv7neon-unknown-linux-musleabihf`: updated in the linked PR
…e, r=Urgau Move `#[rustc_coherence_is_core]` to the `crate_level` file I implemented this one without realizing it already was since it was (in my opinion) in the wrong file and implemented in a batch of all non-crate-level attributes. This commit just cleans it up slightly and moves it. Should be trivial r? `@oli-obk`
rustbot
added
A-attributes
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Sep 17, 2025
Rollup of 9 pull requests Successful merges: - #144871 (Stabilize `btree_entry_insert` feature) - #145181 (remove FIXME block from `has_significant_drop`, it never encounters inference variables) - #145838 (don't apply temporary lifetime extension rules to non-extended `super let`) - #146259 (Suggest removing Box::new instead of unboxing it) - #146410 (Iterator repeat: no infinite loop for `last` and `count`) - #146460 (Add tidy readme) - #146581 (Detect attempt to use var-args in closure) - #146588 (tests/run-make: Update list of statically linked musl targets) - #146647 (Move `#[rustc_coherence_is_core]` to the `crate_level` file) r? `@ghost` `@rustbot` modify labels: rollup
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
Looks like a runner flaked out. 😿 |
|
closing in favor of the larger rollup |
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
btree_entry_insertfeature #144871 (Stabilizebtree_entry_insertfeature)has_significant_drop, it never encounters inference variables #145181 (remove FIXME block fromhas_significant_drop, it never encounters inference variables)super let#145838 (don't apply temporary lifetime extension rules to non-extendedsuper let)lastandcount#146410 (Iterator repeat: no infinite loop forlastandcount)#[rustc_coherence_is_core]to thecrate_levelfile #146647 (Move#[rustc_coherence_is_core]to thecrate_levelfile)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup