-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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 5 pull requests #97667
Rollup of 5 pull requests #97667
Conversation
…=GuillaumeGomez rustdoc: Add more test coverage Related issue rust-lang#91113
update explicit impls error msg
…ding-where-clauses, r=lcnr Fix wrong suggestion for adding where clauses closes rust-lang#97576
don't use a `span_note` for ignored impls Searching for the `derive` isn't too difficult as it's right above the field definition. By using a span these errors are a lot more verbose than they should be, which is especially annoying as one can end up with a lot of `dead_code` warnings.
…n-docs, r=thomcc Improve documentation for constructors of pinned `Box`es Adds a cross-references between `Box::pin` and `Box::into_pin` (and other related methods, i.e. the equivalent `From` implementation, and the unstable `pin_in` method), in particular now that `into_pin` [was stabilized](rust-lang#97397). The main goal is to further improve visibility of the fact that `Box<T> -> Pin<Box<T>>` conversion exits in the first place, and that `Box::pin(x)` is – essentially – just a convenience function for `Box::into_pin(Box::new(x))` The motivating context why I think this is important is even experienced Rust users overlooking the existence this kind of conversion, [e.g. in this thread on IRLO](https://internals.rust-lang.org/t/pre-rfc-function-variants/16732/7?u=steffahn); and also the fact that that discussion brought up that there would be a bunch of Box-construction methods "missing" such as e.g. methods with fallible allocation a la "`Box::try_pin`", and similar; while those are in fact *not* necessary, because you can use `Box::into_pin(Box::try_new(x)?)` instead. I have *not* included explicit mention of methods (e.g. `try_new`) in the docs of stable methods (e.g. `into_pin`). (Referring to unstable API in stable API docs would be bad style IMO.) Stable examples I have in mind with the statement "constructing a (pinned) Box in a different way than with `Box::new`" are things like cloning a `Box`, or `Box::from_raw`. If/when `try_new` would get stabilized, it would become a very good concrete example use-case of `Box::into_pin` IMO.
@bors r+ rollup=never p=5 |
📌 Commit 5b64aab has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (20ad820): comparison url. Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
Successful merges:
span_note
for ignored impls #97645 (don't use aspan_note
for ignored impls)Box
es #97655 (Improve documentation for constructors of pinnedBox
es)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup