-
Notifications
You must be signed in to change notification settings - Fork 13k
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 #70593
Rollup of 6 pull requests #70593
Conversation
Made obsolete by b5e35b1
The wasm32-wasi target delegates its malloc implementation to the functions in wasi-libc, but the invocation of `aligned_alloc` was incorrect by passing the number of bytes requested first rather than the alignment. This commit swaps the order of these two arguments to ensure that we allocate over-aligned memory correctly.
add `unused_braces` lint Add the lint `unused_braces` which is warn by default. `unused_parens` is also extended and now checks anon consts. closes rust-lang#68387 r? @varkor
resolve, `try_resolve_as_non_binding`: use `delay_span_bug` due to parser recovery Fixes rust-lang#70549 r? @petrochenkov
…henkov remove obsolete comment Made obsolete by b5e35b1
…r=Mark-Simulacrum std: Fix over-aligned allocations on wasm32-wasi The wasm32-wasi target delegates its malloc implementation to the functions in wasi-libc, but the invocation of `aligned_alloc` was incorrect by passing the number of bytes requested first rather than the alignment. This commit swaps the order of these two arguments to ensure that we allocate over-aligned memory correctly.
Add `Rust` to the code snippet Adds `Rust` to the snippet where the code causing the ICE should be placed, so github can render it as Rust code rather than plain code.
…n-DPC Fix incorrect documentation for `str::{split_at, split_at_mut}` The documentation for each method currently states: > Panics if `mid` is not on a UTF-8 code point boundary, or if it is beyond the last code point of the string slice. However, this is not consistent with the real behavior, or that of the corresponding methods for `[T]` slices. A comment inside each of the `str` methods states: > is_char_boundary checks that the index is in [0, .len()] That is what I would expect the behavior to be, and in fact this seems to be the real behavior. For example ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8e03dcc209d4dd176df2297523f9fee1)): ```rust fn main() { // Prints ("abc", "") and doesn't panic println!("{:?}", "abc".split_at(3)); } ``` In this case, I would interpret "the last code point of the string slice" to mean the byte at index 2 in UTF-8. However, it is possible to pass an index of 3, which is definitely "beyond the last code point of the string slice". I think that this is much clearer, but feel free to bikeshed.
@bors r+ rollup=never p=6 |
📌 Commit 015217e has been approved by |
⌛ Testing commit 015217e with merge ece0df0a528a1de05a1497000a7ef652e35ad54b... |
💔 Test failed - checks-azure |
@bors treeclosed=1000 |
@bors retry p=1001 |
⌛ Testing commit 015217e with merge a6f9f484166cb64d51187358716ac7eaaba64878... |
💔 Test failed - checks-azure |
@bors retry |
⌛ Testing commit 015217e with merge 121914e18967466b2e813af9e87f5d32c07a2aa3... |
💔 Test failed - checks-azure |
Successful merges:
unused_braces
lint #70081 (addunused_braces
lint)try_resolve_as_non_binding
: usedelay_span_bug
due to parser recovery #70555 (resolve,try_resolve_as_non_binding
: usedelay_span_bug
due to parser recovery)Rust
to the code snippet #70587 (AddRust
to the code snippet)str::{split_at, split_at_mut}
#70588 (Fix incorrect documentation forstr::{split_at, split_at_mut}
)Failed merges:
r? @ghost