-
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 6 pull requests #91159
Rollup of 6 pull requests #91159
Conversation
A byproduct of using `<details>` and `<summary>` to show/hide detailed documentation was that clicking any part of a method heading (or impl heading) would show or hide the documentation. This was not super noticeable because clicking a link inside the method heading would navigate to that link. But clicking any unlinked black text in a method heading would trigger the behavior. That behavior was somewhat unexpected, and means that if you try to click a type name in a method heading, but miss by a few pixels, you get a confusing surprise. This change inhibits that behavior by putting an event listener on most summaries that cancels the event unless the event target was the summary itself. In practice, that means it cancels the event unless the target was the "[+]" / "[-]", because the rest of the heading is wrapped inside a `<div>`, which is the target for anything that doesn't have a more specific target.
Doc Jones mentioned that one of the things making it hard to get started is that the amount of information is overwhelming, between the dev-guide, contributing guide, and discussion platforms. This gives people a single link they can click to ask for help.
According to documentation, the listed errnos should only occur if the `copy_file_range` call cannot be made at all, so the assert be correct. However, since in practice file system drivers (incl. FUSE etc.) can return any errno they want, we should not panic here. Fixes rust-lang#91152
…llocator-api-in-tuple, r=davidtwco Suggestion to wrap inner types using 'allocator_api' in tuple This PR provides a suggestion to wrap the inner types in tuple when being along with 'allocator_api'. Closes rust-lang#83250 ```rust fn main() { let _vec: Vec<u8, _> = vec![]; //~ ERROR use of unstable library feature 'allocator_api' } ``` ```diff error[E0658]: use of unstable library feature 'allocator_api' --> $DIR/suggest-vec-allocator-api.rs:2:23 | LL | let _vec: Vec<u8, _> = vec![]; - | ^ + | ----^ + | | + | help: consider wrapping the inner types in tuple: `(u8, _)` | = note: see issue rust-lang#32838 <rust-lang#32838> for more information = help: add `#![feature(allocator_api)]` to the crate attributes to enable ```
…, r=Manishearth,GuillaumeGomez Inhibit clicks on summary's children A byproduct of using `<details>` and `<summary>` to show/hide detailed documentation was that clicking any part of a method heading (or impl heading) would show or hide the documentation. This was not super noticeable because clicking a link inside the method heading would navigate to that link. But clicking any unlinked black text in a method heading would trigger the behavior. That behavior was somewhat unexpected, and means that if you try to click a type name in a method heading, but miss by a few pixels, you get a confusing surprise. This change inhibits that behavior by putting an event listener on most summaries that cancels the event unless the event target was the summary itself. In practice, that means it cancels the event unless the target was the "[+]" / "[-]", because the rest of the heading is wrapped inside a `<div>`, which is the target for anything that doesn't have a more specific target. r? ``@Manishearth``
Give people a single link they can click in the contributing guide Doc Jones mentioned that one of the things making it hard to get started is that the amount of information is overwhelming, between the dev-guide, contributing guide, and discussion platforms. This gives people a single link they can click to ask for help. cc ``@doc-jones`` - is this what you had in mind?
Split inline const to two feature gates and mark expression position inline const complete This PR splits inline const in pattern position into its own `#![feature(inline_const_pat)]` feature gate, and make the usage in expression position complete. I think I have resolved most outstanding issues related to `inline_const` with rust-lang#89561 and other PRs. The only thing left that I am aware of is rust-lang#90150 and the lack of lifetime checks when inline const is used in pattern position (FIXME in rust-lang#89561). Implementation-wise when used in pattern position it has to be lowered during MIR building while in expression position it's evaluated only when monomorphizing (just like normal consts), so it makes some sense to separate it into two feature gates so one can progress without being blocked by another. ``@rustbot`` label: T-compiler F-inline_const
…enkov Use `derive_default_enum` in the compiler Let's get this feature some real-world love. ``@rustbot`` label: +C-cleanup +S-waiting-on-review
…the8472 kernel_copy: avoid panic on unexpected OS error According to documentation, the listed errnos should only occur if the `copy_file_range` call cannot be made at all, so the assert be correct. However, since in practice file system drivers (incl. FUSE etc.) can return any errno they want, we should not panic here. Fixes rust-lang#91152
@bors r+ rollup=never p=6 |
📌 Commit 3dc0011 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (65c55bf): comparison url. Summary: This change led to moderate relevant improvements 🎉 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Successful merges:
derive_default_enum
in the compiler #91148 (Usederive_default_enum
in the compiler)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup