Skip to content
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 8 pull requests #94072

Merged
merged 18 commits into from
Feb 17, 2022
Merged

Rollup of 8 pull requests #94072

merged 18 commits into from
Feb 17, 2022

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

kpreid and others added 18 commits December 4, 2021 07:46
For users looking at documentation through IDE popups, this gives them
relevant information rather than the generic trait documentation wording
“Performs the conversion”. For users reading the documentation for a
specific type for any reason, this informs them when the conversion may
allocate or copy significant memory versus when it is always a move or
cheap copy.

Notes on specific cases:
* The new documentation for `From<T> for T` explains that it is not a
  conversion at all.
* Also documented `impl<T, U> Into<U> for T where U: From<T>`, the other
  central blanket implementation of conversion.
* I did not add documentation to conversions of a specific error type to
  a more general error type.
* I did not add documentation to unstable code.

This change was prepared by searching for the text "From<... for" and so
may have missed some cases that for whatever reason did not match. I
also looked for `Into` impls but did not find any worth documenting by
the above criteria.
Essentially, what is described here:
rust-lang#64888 (comment)

There is one difference. The comment proposes to add a
`--report-time-color` option. This change instead uses libtest's
existing `--color` option for that purpose.
It should only include the identifier, or misspelling suggestions will be wrong.
Add documentation to more `From::from` implementations.

For users looking at documentation through IDE popups, this gives them relevant information rather than the generic trait documentation wording “Performs the conversion”. For users reading the documentation for a specific type for any reason, this informs them when the conversion may allocate or copy significant memory versus when it is always a move or cheap copy.

Notes on specific cases:
* The new documentation for `From<T> for T` explains that it is not a conversion at all.
* Also documented `impl<T, U> Into<U> for T where U: From<T>`, the other central blanket implementation of conversion.
* The new documentation for construction of maps and sets from arrays of keys mentions the handling of duplicates. Future work could be to do this for *all* code paths that convert an iterable to a map or set.
* I did not add documentation to conversions of a specific error type to a more general error type.
* I did not add documentation to unstable code.

This change was prepared by searching for the text "From<... for" and so may have missed some cases that for whatever reason did not match. I also looked for `Into` impls but did not find any worth documenting by the above criteria.
Use `optflag` for `--report-time`

Essentially, what is described here:
rust-lang#64888 (comment)

There is one difference. The comment proposes to add a
`--report-time-color` option. This change instead uses libtest's
existing `--color` option for that purpose.
Suggest deriving required supertraits

closes rust-lang#91550

I chose to just hardcode handling for PartialOrd and PartialEq because that should be robust enough and I dont know how to go about doing it generically

r? rust-lang/diagnostics
…-option-result, r=davidtwco

Fix suggestion to slice if scurtinee is a reference to `Result` or `Option`

Fixes rust-lang#91343 (comment) and rust-lang#91343 (comment).
…es-a-function, r=petrochenkov

Do not suggest "is a function" for free variables

Part of rust-lang#82323
…ochenkov

Correctly mark the span of captured arguments in `format_args!()`

It should not include the braces, or misspelling suggestions will be wrong.

Fixes rust-lang#94010.
…on-drop-suggest-copy-bound-alternative, r=davidtwco

[diagnostics] Add mentions to `Copy` types being valid for `union` fields

This came up from some user on Discord which was using a `T : PrimitiveInt` generic type, and they wanted to use in a `union`. Rather than adding a `Copy` bound, they started pondering about the `ManuallyDrop<T>` road, and how to correctly use `unsafe` to perform the drops.

<img width="648" alt="Screen Shot 2022-02-15 at 22 28 34" src="https://user-images.githubusercontent.com/9920355/154152496-8f9be74b-ad59-4724-8f9e-48b446774e06.png">

  - [Discord link](https://discord.com/channels/442252698964721669/443150878111694848/943092778534072320)

So, it seemed like the error message for types with potential drop glue on `union` fields could be improved to also mention the `Copy` alternative, since in many cases where `union`s are concerned, people are dealing with PODs / `Copy` types anyways 🙂

___

``@rustbot`` modify labels: +A-diagnostics +D-terse
…ulacrum

Update dist-x86_64-musl to Ubuntu 20.04

This updates the dist-x86_64-musl image to use Ubuntu 20.04. The current Ubuntu 16.04 based image only works due to the Docker cache, it's not possible anymore to run it locally because of the usual certificate expiration issue.

I believe updating the OS here is relatively safe because this targets musl, so there are no concerns about raising the glibc baseline. There is some risk here in that it updates the compiler toolchain used to produce artifacts, though I'm not aware of any specific issues that could cause.

r? ``@Mark-Simulacrum``
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Feb 17, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=8

@bors
Copy link
Contributor

bors commented Feb 17, 2022

📌 Commit aa83189 has been approved by matthiaskrgr

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Feb 17, 2022
@bors
Copy link
Contributor

bors commented Feb 17, 2022

⌛ Testing commit aa83189 with merge 582b696...

@bors
Copy link
Contributor

bors commented Feb 17, 2022

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 582b696 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Feb 17, 2022
@bors bors merged commit 582b696 into rust-lang:master Feb 17, 2022
@rustbot rustbot added this to the 1.60.0 milestone Feb 17, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (582b696): comparison url.

Summary: This benchmark run shows 17 relevant regressions 😿 to instruction counts.

  • Average relevant regression: 11.3%
  • Largest regression in instruction counts: 157.0% on full builds of stm32f4 doc

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

@rustbot rustbot added the perf-regression Performance regression. label Feb 17, 2022
@rylev
Copy link
Member

rylev commented Feb 24, 2022

@matthiaskrgr is it possible this is caused by #89869 which adds docs to a bunch of blanket impls? The regressions are only in docs, and I don't see anything else that looks suspicious. Looks like the regression is happening in render_item which I think would be called more if there are simply more things to document.

@matthiaskrgr matthiaskrgr deleted the rollup-7uu2286 branch March 11, 2022 15:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.