-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 7 pull requests #100318
Rollup of 7 pull requests #100318
Conversation
This attribute allows to mark default body of a trait function as unstable. This means that implementing the trait without implementing the function will require enabling unstable feature. This is useful in conjunction with `#[rustc_must_implement_one_of]`, we may want to relax requirements for a trait, for example allowing implementing either of `PartialEq::{eq, ne}`, but do so in a safe way -- making implementation of only `PartialEq::ne` unstable.
Because python doesn't have lexical scope, loop variables persist after the loop is exited, set to the value of the last itteration ``` >>> i = 0 >>> for i in range(10): pass ... >>> i 9 ``` This causes the `ty` variable to be changed, causing unexpected crashes on ``` pub type RefFn<'a> = &'a dyn for<'b> Fn(&'a i32) -> i32; ```
When an item isn't found, we may suggest an appropriate import to `use`. Along with that, we also suggest updating the path to work with the `use`. Unfortunately, if the code in question originates from a macro, the span used to indicate which part of the path needs updating may not be suitable and cause an ICE. Since, such code is not adjustable directly by the user without modifying the macro, just skip the suggestion in such cases.
…table, r=Aaron1011 Implement `#[rustc_default_body_unstable]` This PR implements a new stability attribute — `#[rustc_default_body_unstable]`. `#[rustc_default_body_unstable]` controls the stability of default bodies in traits. For example: ```rust pub trait Trait { #[rustc_default_body_unstable(feature = "feat", isssue = "none")] fn item() {} } ``` In order to implement `Trait` user needs to either - implement `item` (even though it has a default implementation) - enable `#![feature(feat)]` This is useful in conjunction with [`#[rustc_must_implement_one_of]`](rust-lang#92164), we may want to relax requirements for a trait, for example allowing implementing either of `PartialEq::{eq, ne}`, but do so in a safe way — making implementation of only `PartialEq::ne` unstable. r? `@Aaron1011` cc `@nrc` (iirc you were interested in this wrt `read_buf`), `@danielhenrymantilla` (you were interested in the related `#[rustc_must_implement_one_of]`) P.S. This is my first time working with stability attributes, so I'm not sure if I did everything right 😅
…triddle,GuillaumeGomez Rustdoc-Json: Document HRTB's on DynTrait Closes rust-lang#99118 Probably best reviewed commit by commit. `@rustbot` modify labels: +A-rustdoc-json cc `@Enselic` r? `@CraftSpider`
…ackh726 add method to get the mutability of an AllocId Miri needs this for rust-lang/miri#2463.
…tems, r=lcnr,notriddle,camelid Don't document impossible to call default trait items on impls Closes rust-lang#100176 This only skips documenting _default_ trait items on impls, not ones that are written inside the impl block. This is a conservative approach, since I think we should document all items written in an impl block (I guess unless hidden or whatever), but the existence of this new query I added makes this easy to extend to other rustdoc cases.
Don't ICE while suggesting updating item path. When an item isn't found, we may suggest an appropriate import to `use`. Along with that, we also suggest updating the path to work with the `use`. Unfortunately, if the code in question originates from a macro, the span used to indicate which part of the path needs updating may not be suitable and cause an ICE (*). Since, such code is not adjustable directly by the user without modifying the macro, just skip the suggestion in such cases. (*) The ICE happens because the emitter want to indicate to the user what code to delete by referencing a certain span. But in this case, said span has `lo == hi == 0` which means it thinks it's a dummy span. Adding a space before the proc macro attribute is enough to stop it from ICE'ing but even then the suggestion doesn't really make any sense: ``` help: if you import `DataStore`, refer to it directly | 1 - #[dbstruct::dbstruct] 1 + #[dbstruct::dbstruct] ``` Since suggestions are best-effort, I just gated this one on `can_be_used_for_suggestions` which catches cases like this. Fixes rust-lang#100199
…rsions, r=compiler-errors Avoid `&str` to `String` conversions This patch removes the recently added unnecessary `&str` to `String` conversions. follow-up to rust-lang#99718
…-missing-pattern-excluding-comments, r=compiler-errors Suggest adding an appropriate missing pattern excluding comments fixes rust-lang#100272
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR: In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (6d3f1be): comparison url. Instruction count
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:
#[rustc_default_body_unstable]
#96478 (Implement#[rustc_default_body_unstable]
)&str
toString
conversions #100301 (Avoid&str
toString
conversions)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup