Rollup of 19 pull requests #143061
Rollup of 19 pull requests #143061
Conversation
No need to call into fold when the first item is already None, this avoids some redundant work for empty iterators. "But it uses Fuse" one might want to protest, but Fuse is specialized and may call into the inner iterator anyway.
It is currently possible to create a dangling `Weak` to a DST by calling `Weak::new()` for a sized type, then doing an unsized coercion. Therefore, the comments are wrong. These comments were added in <rust-lang#73845>. As far as I can tell, the guarantee in the comment was only previously used in the `as_ptr` method. However, the current implementation of `as_ptr` no longer relies on this guarantee.
…t comes from expansion
…ing from expansion
…it_links` new API
```
error[E0382]: borrow of moved value: `x`
--> $DIR/moves-based-on-type-capture-clause-bad.rs:9:20
|
LL | let x = "Hello world!".to_string();
| - move occurs because `x` has type `String`, which does not implement the `Copy` trait
LL | thread::spawn(move || {
| ------- value moved into closure here
LL | println!("{}", x);
| - variable moved due to use in closure
LL | });
LL | println!("{}", x);
| ^ value borrowed here after move
|
= note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider cloning the value before moving it into the closure
|
LL ~ let value = x.clone();
LL ~ thread::spawn(move || {
LL ~ println!("{}", value);
|
```
…ssible_obligation
This centralizes the placeholder type error reporting in one location, but it also exposes the granularity at which we convert things from hir to ty more. E.g. previously infer types in where bounds were errored together with the function signature, but now they are independent.
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
Suggest cloning `Arc` moved into closure
```
error[E0382]: borrow of moved value: `x`
--> $DIR/moves-based-on-type-capture-clause-bad.rs:9:20
|
LL | let x = "Hello world!".to_string();
| - move occurs because `x` has type `String`, which does not implement the `Copy` trait
LL | thread::spawn(move || {
| ------- value moved into closure here
LL | println!("{}", x);
| - variable moved due to use in closure
LL | });
LL | println!("{}", x);
| ^ value borrowed here after move
|
= note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider cloning the value before moving it into the closure
|
LL ~ let value = x.clone();
LL ~ thread::spawn(move || {
LL ~ println!("{}", value);
|
```
Fix rust-lang#104232.
Simplify `ObligationCauseCode::IfExpression` This originally started out as an experiment to do less incremental invalidation by deferring the span operations that happen on the good path in `check_expr_if`, but it ended up not helping much (or at least not showing up in our incremental tests). As a side-effect though, I think the code is a lot cleaner and there are modest diagnostics improvements with overlapping spans, so I think it's still worth landing.
…eyouxu make `tidy-alphabetical` use a natural sort The idea here is that these lines should be correctly sorted, even though a naive string comparison would say they are not: ``` foo2 foo10 ``` This is the ["natural sort order"](https://en.wikipedia.org/wiki/Natural_sort_order). There is more discussion in [#t-compiler/help > tidy natural sort](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/tidy.20natural.20sort/with/519111079) Unfortunately, no standard sorting tools are smart enough to to this automatically (casting some doubt on whether we should make this change). Here are some sort outputs: ``` > cat foo.txt | sort foo foo1 foo10 foo2 mp mp1e2 np", np1e2", > cat foo.txt | sort -n foo foo1 foo10 foo2 mp mp1e2 np", np1e2", > cat foo.txt | sort -V foo foo1 foo2 foo10 mp mp1e2 np1e2", np", ``` Disappointingly, "numeric" sort does not actually have the behavior we want. It only sorts by numeric value if the line starts with a number. The "version" sort looks promising, but does something very unintuitive if you look at the final 4 values. None of the other options seem to have the desired behavior in all cases: ``` -b, --ignore-leading-blanks ignore leading blanks -d, --dictionary-order consider only blanks and alphanumeric characters -f, --ignore-case fold lower case to upper case characters -g, --general-numeric-sort compare according to general numerical value -i, --ignore-nonprinting consider only printable characters -M, --month-sort compare (unknown) < 'JAN' < ... < 'DEC' -h, --human-numeric-sort compare human readable numbers (e.g., 2K 1G) -n, --numeric-sort compare according to string numerical value -R, --random-sort shuffle, but group identical keys. See shuf(1) --random-source=FILE get random bytes from FILE -r, --reverse reverse the result of comparisons --sort=WORD sort according to WORD: general-numeric -g, human-numeric -h, month -M, numeric -n, random -R, version -V -V, --version-sort natural sort of (version) numbers within text ``` r? ````@Noratrieb```` (it sounded like you know this code?)
…links-expansion, r=lolbinarycat [rustdoc] Do not emit redundant_explicit_links lint if the doc comment comes from expansion Fixes rust-lang#141553. The problem was that we change the context for the attributes in some cases to get better error output, preventing us to detect if the attribute comes from expansion. Most of the changes are about keeping track of the "does this span comes from expansion" information. r? ````@Manishearth````
…ly, r=nnethercote tests: Do not run afoul of asm.validity.non-exhaustive in input-stats This addresses one of the three powerpc64-unknown-linux-musl test failures in rust-lang#142280 I was motivated to cover it myself because technically this is also compile-time UB if we compile a program that has `asm!` with x86-64-specific instructions on another platform. That'll only mean something if this is ever switched to build-pass, or if checking emits object code, but conveniently "nop" is valid assembly on all platforms anyone has implemented Rust codegen for. Even the weird ones LLVM doesn't support, like PA-RISC or Common Intermediate Language. ...except GPUs. Not sure about those. r? ````@nnethercote````
rustbot
added
T-infra
|
@bors r+ rollup=never p=10 |
bors
added
S-waiting-on-bors
|
🙏 |
|
looks like this overlaps with a couple of rollups that are already in the queue, please don't make overlapping rollups! |
|
Matthias, do not close my rollup in favor of smaller rollups. |
|
@bors r+ rollup=never p=10 |
|
💡 This pull request was already approved, no need to approve it again.
|
|
I have absolutely no idea why we'd want to test a smaller rollup in favor of a larger one. Don't micromanage my rollups, thanks; if this fails to merge for some reason then it'll move onto the smaller one. |
|
its pretty simple: test failure: no progress on the queue :( It would be great if you could stop shoving your rollups in front of other peoples rollups. |
These are almost all rollup=always PRs. There is very little risk of perf regressions, bisections happen automatically with cargo-bisect-rustc, and I'm not worried about conflicts (which is also a signal we'd want to bubble up as soon as possible, of course). And as the person who made the rollup, I'm obviously taking responsibility to triage perf regressions and I've done so pretty consistently before.
The point of a rollup is to test things; It's been explained many times before that even failed rollups provide signal for the merge queue. |
|
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message |
bors
added
S-waiting-on-author
|
Due to oli's infer var pr. |
|
ok then please only run try jobs to do testing on your mega rollups, that would be greatly appreciated, and don't put them into the merge queue! |
|
My last rollup failed because of a rollup=always PR, and your rollup failed too. You don't actually have any idea what the "good PRs" are. |
|
☔ The latest upstream changes (presumably #142255) made this pull request unmergeable. Please resolve the merge conflicts. |
Successful merges:
Arcmoved into closure #124595 (Suggest cloningArcmoved into closure)ObligationCauseCode::IfExpression#139594 (SimplifyObligationCauseCode::IfExpression)tidy-alphabeticaluse a natural sort #141311 (maketidy-alphabeticaluse a natural sort)Weak#142700 (Remove incorrect comments inWeak)#[used]to new attribute parsing infrastructure #142818 (Port#[used]to new attribute parsing infrastructure)browser-ui-testversion to0.20.7#143010 (Updatebrowser-ui-testversion to0.20.7)sym::macro_pindiagnostic item forcore::pin::pin!()#143015 (Addsym::macro_pindiagnostic item forcore::pin::pin!())Failed merges:
#[export_name]to the new attribute parsing infrastructure #142986 (Port#[export_name]to the new attribute parsing infrastructure)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup