-
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 9 pull requests #94065
Closed
Closed
Rollup of 9 pull requests #94065
Conversation
This file contains 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
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.
I have found this code confusing for years. I've always roughly understood it, but never exactly. I just made my fourth(?) attempt and finally cracked it. This commit improves the comments. In particular, it explicitly describes how you can't do a custom fold/visit of any type; there are actually a handful of "types of interest" (e.g. `Ty`, `Predicate`, `Region`, `Const`) that can be custom folded/visted, and all other types just get a generic traversal. I think this was the part that eluded me on all my prior attempts at understanding. The commit also updates comments to account for some newer changes such as the fallible/infallible folding distinction, does some minor reorderings, and moves one `impl` to a better place.
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
…s, r=BoxyUwU Improve comments about type folding/visiting. I have found this code confusing for years. I've always roughly understood it, but never exactly. I just made my fourth(?) attempt and finally cracked it. This commit improves the comments. In particular, it explicitly describes how you can't do a custom fold/visit of any type; there are actually a handful of "types of interest" (e.g. `Ty`, `Predicate`, `Region`, `Const`) that can be custom folded/visted, and all other types just get a generic traversal. I think this was the part that eluded me on all my prior attempts at understanding. The commit also updates comments to account for some newer changes such as the fallible/infallible folding distinction, does some minor reorderings, and moves one `impl` to a better place. r? `@BoxyUwU`
…-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
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 16, 2022
@bors r+ rollup=never p=9 |
📌 Commit d0961c3 has been approved by |
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 16, 2022
⌛ Testing commit d0961c3 with merge 6f18ccd5cf3c54025f60ec6fa9585a6f01c29f48... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Feb 17, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
rollup
A PR which is a rollup
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
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:
From::from
implementations. #89869 (Add documentation to moreFrom::from
implementations.)optflag
for--report-time
#93479 (Useoptflag
for--report-time
)Result
orOption
#93981 (Fix suggestion to slice if scurtinee is a reference toResult
orOption
)format_args!()
#94030 (Correctly mark the span of captured arguments informat_args!()
)Copy
types being valid forunion
fields #94031 ([diagnostics] Add mentions toCopy
types being valid forunion
fields)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup