-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 13 pull requests #40651
Rollup of 13 pull requests #40651
Conversation
Point at the immutable local variable when trying to modify one of its fields. Given a file: ```rust struct Foo { pub v: Vec<String> } fn main() { let f = Foo { v: Vec::new() }; f.v.push("cat".to_string()); } ``` present the following output: ``` error: cannot borrow immutable field `f.v` as mutable --> file.rs:7:13 | 6 | let f = Foo { v: Vec::new() }; | - this should be `mut` 7 | f.v.push("cat".to_string()); | ^^^ error: aborting due to previous error ```
Change the wording of mutable borrow on immutable binding from "this should be `mut`" to "consider changing this to `mut f`".
It does not seem valuable to always evaluate the right-hand side here.
This seems to match other uses of "be accessed" in the document.
… to be more precise.
The name of the variable used in the example is `path`, not `os_str`.
Add feature gate for rvalue-static-promotion Probably needs more tests (which ones?) and there may be other things that need to be done. Also not sure whether the version that introduces the flag is really `1.15.1`. See rust-lang/rfcs#1414. Updates rust-lang#38865.
…rner Point to let when modifying field of immutable variable Point at the immutable local variable when trying to modify one of its fields. Given a file: ```rust struct Foo { pub v: Vec<String> } fn main() { let f = Foo { v: Vec::new() }; f.v.push("cat".to_string()); } ``` present the following output: ``` error: cannot borrow immutable field `f.v` as mutable --> file.rs:7:13 | 6 | let f = Foo { v: Vec::new() }; | - this should be `mut` 7 | f.v.push("cat".to_string()); | ^^^ error: aborting due to previous error ``` Fix rust-lang#27593.
Remove unused param from bootstrap::clean::rm_rf None
…wsxcv Fix const not displayed in rustdoc Fixes rust-lang#40331. r? @rust-lang/docs
…ion, r=nrc macros: fix regression with `include!()` Fixes rust-lang#40469, a regression when `include!()`ing a `macro_rules!` containing `$crate`. r? @nrc
…excrichton Add a test for issue 34571 Closes rust-lang#34571.
… r=nagisa Parse 0e+10 as a valid floating-point literal Fixes issue rust-lang#40408.
documented order of conversion between u32 an ipv4addr This fixes rust-lang#40118
…uillaumeGomez minor wording tweak to slice::{as_ptr, as_mut_ptr} Per rust-lang#37334, the slice-as-pointer methods mentioned that "modifying the slice may cause its buffer to be reallocated", when in fact modifying the *slice* itself would cause no such change. (It is a borrow, after all!) This is a tweak to the wording of that line to stress it's the *collection* that could cause the buffer to be reallocated. r? @steveklabnik
Fix typo in mutex.rs docs This seems to match other uses of "be accessed" in the document.
…sfackler Fix a spelling error in HashMap documentation, and slightly reword surrounding text for precision Noticed while reading docs just now. It's possible that the prior wording *meant* to state that the seed's randomness depends on the exact instant that the system RNG was created, I guess. But unless there's an API guarantee that this is the case, the wording seems over-precise. Is there a formal API guarantee that would forbid, say, the system RNG from generating all output using the Intel RDRAND instruction? I don't think the quality of output in that case would depend on when the RNG was created. Yet it seems to me like it could well be a valid source of randomness when computing the initial seed. For that reason, tying the randomness of the seed, to the quality of the RNG's output *at the precise instant the seed is computed*, seems less confining. That instantaneous quality level could be determined by the quality at the instant the RNG was created -- but instantaneous quality need not be low for that precise reason.
…r=frewsxcv Add mention of None as possible return. Closes rust-lang#40435. This commit adds a small mention to some methods that None is returned when the slice is empty.
Fix a typo in path.rs docs The name of the variable used in the example is `path`, not `os_str`.
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @eddyb (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
@bors r+ p=10 |
📌 Commit 94e346b has been approved by |
☀️ Test successful - status-appveyor, status-travis |
include!()
#40583, Add a test for issue 34571 #40588, Parse 0e+10 as a valid floating-point literal #40589, documented order of conversion between u32 an ipv4addr #40590, minor wording tweak to slice::{as_ptr, as_mut_ptr} #40603, Fix typo in mutex.rs docs #40611, Fix a spelling error in HashMap documentation, and slightly reword surrounding text for precision #40621, Add mention of None as possible return. Closes #40435. #40646, Fix a typo in path.rs docs #40648