Rollup of 8 pull requests #146830
Merged
Rollup of 8 pull requests #146830
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The `cargo asm` tool pattern matches on such labels to figure out where functions end: normal functions generated by LLVM always do have such a label. We don't guarantee that naked functions emit such a label, but having `cargo asm` work is convenient
Although these types aren't directly constructable externally, since they're pub, I think this omission was an oversight.
Improve doc of some methods that take ranges Some methods that were taking some range in parameter were a bit inconsistent / unclear in the panic documentation. Here is the recap: - Replaced "start/end point" by "start/end bound" to be coherent with [`RangeBounds`](https://doc.rust-lang.org/stable/std/ops/trait.RangeBounds.html) naming (it's also easier to understand I think) - Previously, it was written "_[...] or if the end point is greater than the length of [...]_", but this is not entirely true! Actually, you can have a start bound that is greater than the length, with an end bound that is unbounded and it will also panic. Therefore I think that "_[...] one of the range bound is bounded and greater than the length of [...]_" is better! - `String` methods weren't mentionning that the method panics if `start_bound > end_bound` but it actually does! It uses `slice::range` which panics when `start > end`. (https://doc.rust-lang.org/stable/src/alloc/string.rs.html#1932-1934, https://doc.rust-lang.org/stable/src/core/slice/index.rs.html#835-837). You can also test it with: ```rs struct MyRange; impl std::ops::RangeBounds<usize> for MyRange { fn start_bound(&self) -> std::ops::Bound<&usize> { std::ops::Bound::Included(&3usize) } fn end_bound(&self) -> std::ops::Bound<&usize> { std::ops::Bound::Included(&1usize) } } fn main() { let mut s = String::from("I love Rust!"); s.drain(MyRange); // panics! } ```
…r=Mark-Simulacrum Stabilize `new_zeroed_alloc` The corresponding `new_uninit` and `new_uninit_slice` functions were stabilized in rust-lang#129401, but the zeroed counterparts were left for later out of a [desire](rust-lang#63291 (comment)) to stabilize only the minimal set. These functions are straightforward mirrors of the uninit functions and well-established. Since no blockers or design questions have surfaced in the past year, I think it's time to stabilize them. Tracking issue: rust-lang#129396
…k-Simulacrum Stabilize `std::panic::Location::file_as_c_str` Closes: rust-lang#141727 Nominating this for T-lang as per ```@traviscross``` rust-lang#141727 (comment)
…r=workingjubilee fix issue with `cmse-nonsecure-entry` ABI being both async and c-variadic tracking issue: rust-lang#75835 fixes rust-lang#132142 An `extern "cmse-nonsecure-entry"` function cannot be c-variadic (or, in any case, clang/LLVM does not support it, see https://godbolt.org/z/MaPjzGcE1). So just stop looking at the type if we know it'll be invalid anyway. I'm not entirely sure how to test this. The ICE is only possible on the `thumbv8m.main-none-eabi` and some related targets. I think using `minicore` is the most convenient, but use of `async` requires quite a long list of lang items to be present. Maybe we want that anyway though? On the other hand, it's extra `minicore` surface that might go out of date. An alternative is `run-make`, that should work, but is much less convenient. See also [#t-compiler/help > &rust-lang#96;async fn&rust-lang#96; and &rust-lang#96;minicore&rust-lang#96;](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/.60async.20fn.60.20and.20.60minicore.60/with/539427262). r? `@ghost`
…=cjgillot Deref related cleanups in ref_prop Cherry picked from rust-lang#146710 r? cjgillot
…manieu naked_asm: emit a label starting with `func_end` The `cargo asm` tool (`cargo install cargo-show-asm`) pattern matches on such labels to figure out where functions end: normal functions generated by LLVM always do have such a label. We don't guarantee that naked functions emit such a label, but having `cargo asm` work is convenient. https://github.com/pacak/cargo-show-asm/blob/be45f67454ad8b634246a7fc69b3c6a963ee93f1/src/asm/statements.rs#L897-L901 To make the label name unique it's suffixed with the name of the current symbol. r? ```@Amanieu```
Add unstable attribute to BTreeMap-related allocator generics Although these types aren't directly constructable externally, since they're pub, I think this omission was an oversight. r? libs-api
Fix old typo in lang_start_internal comment Noticed this when reading the rt cleanup code; the typo was introduced during a mass port of libstd to std in comments.
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: dd7fda5700 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing dd7fda5 (parent) -> dfa2223 (this PR) Test differencesShow 1154 test diffsStage 1
Stage 2
Additionally, 1150 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard dfa22235d858086511bedc4acde9db1c045ffbac --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (dfa2223): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -2.0%, secondary -3.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 472.936s -> 472.257s (-0.14%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
new_zeroed_alloc#144091 (Stabilizenew_zeroed_alloc)std::panic::Location::file_as_c_str#145664 (Stabilizestd::panic::Location::file_as_c_str)cmse-nonsecure-entryABI being both async and c-variadic #146551 (fix issue withcmse-nonsecure-entryABI being both async and c-variadic)func_end#146793 (naked_asm: emit a label starting withfunc_end)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup