Rollup of 8 pull requests #122182
Rollup of 8 pull requests #122182
Conversation
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
This makes more sense because most cases then second one is unwind target.
Some implementations of `Write::write_vectored` in the standard library (`BufWriter`, `LineWriter`, `Stdout`, `Stderr`) check all buffers to calculate the total length. This is O(n) over the number of buffers. It's common that only a limited number of buffers is written at a time (e.g. 1024 for `writev(2)`). `write_vectored_all` will then call `write_vectored` repeatedly, leading to a runtime of O(n²) over the number of buffers. The fix is to only calculate as much as needed if it's needed.
@rustbot label: +llvm-main
Improve std::fs::read_to_string example Resolves [rust-lang#118621](rust-lang#118621) For the original code to succeed it requires address.txt to contain a socketaddress, however it is much easier to follow if this is just any strong - eg address could be a street address or just text. Also changed the variable name from "foo" to something more meaningful as cargo clippy warns you against using foo as a placeholder. ``` $ cat main.rs use std::fs; use std::error::Error; fn main() -> Result<(), Box<dyn Error>> { let addr: String = fs::read_to_string("address.txt")?.parse()?; println!("{}", addr); Ok(()) } $ cat address.txt 123 rusty lane san francisco 94999 $ cargo run Finished dev [unoptimized + debuginfo] target(s) in 0.00s Running `/home/haydon/workspace/rust-test-pr/tester/target/debug/tester` 123 rusty lane san francisco 94999 ```
Add asm goto support to `asm!` Tracking issue: rust-lang#119364 This PR implements asm-goto support, using the syntax described in "future possibilities" section of [RFC2873](https://rust-lang.github.io/rfcs/2873-inline-asm.html#asm-goto). Currently I have only implemented the `label` part, not the `fallthrough` part (i.e. fallthrough is implicit). This doesn't reduce the expressive though, since you can use label-break to get arbitrary control flow or simply set a value and rely on jump threading optimisation to get the desired control flow. I can add that later if deemed necessary. r? ``@Amanieu`` cc ``@ojeda``
Docs for std::ptr::slice_from_raw_parts
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 14fbc3c005 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (1b2c53a): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 648.483s -> 652.903s (0.68%) |
|
The bootstrap regression looks real. @rust-timer build 495b677 |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (495b677): comparison URL. Overall result: ❌ regressions - no action neededInstruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 648.483s -> 651.069s (0.40%) |
|
Visiting for weekly perf triage
|
|
to be honest I am not completely unamused by the fact that "our build took 5 seconds longer" is considered a serious regression :D @rust-timer build bdb9576 |
This comment has been minimized.
This comment has been minimized.
|
It's not necessarily about the regression itself (I'd personally OK it), just that it would be nice to know what has caused it (if it is real), so that we can have a better idea about what effects do various code changes have on the compilation time of |
|
Plus rustc is the only benchmark we have that is not just a single crate, so it's interesting in that way. |
|
Finished benchmarking commit (bdb9576): comparison URL. Overall result: ❌ regressions - no action neededInstruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 648.483s -> 648.725s (0.04%) |
|
🤔 |
|
That's just LLVM artifact size tracking working again. The unrolled build was created too soon, so it still contained an old |
marking as triaged @rustbot label: +perf-regression-triaged |
rustbot
added
the
perf-regression-triaged
Successful merges:
asm!#119365 (Add asm goto support toasm!)loongarch64-unknown-linux-musl#121832 (Add new Tier-3 target:loongarch64-unknown-linux-musl)#[inline]toBTreeMap::newconstructor #122099 (Add#[inline]toBTreeMap::newconstructor)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup