Skip to content

Rollup of 7 pull requests #122176

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
wants to merge 33 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

haydonryan and others added 30 commits December 11, 2023 11:41
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.
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`
…, r=oli-obk

Move generic `NonZero` `rustc_layout_scalar_valid_range_start` attribute to inner type.

Tracking issue: rust-lang#120257

r? `@dtolnay`
…r=Amanieu

Fix quadratic behavior of repeated vectored writes

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.

This fix is to only calculate as much as needed if it's needed.

Here's a test program:
```rust
#![feature(write_all_vectored)]

use std::fs::File;
use std::io::{BufWriter, IoSlice, Write};
use std::time::Instant;

fn main() {
    let buf = vec![b'\0'; 100_000_000];
    let mut slices: Vec<IoSlice<'_>> = buf.chunks(100).map(IoSlice::new).collect();
    let mut writer = BufWriter::new(File::create("/dev/null").unwrap());

    let start = Instant::now();
    write_smart(&slices, &mut writer);
    println!("write_smart(): {:?}", start.elapsed());

    let start = Instant::now();
    writer.write_all_vectored(&mut slices).unwrap();
    println!("write_all_vectored(): {:?}", start.elapsed());
}

fn write_smart(mut slices: &[IoSlice<'_>], writer: &mut impl Write) {
    while !slices.is_empty() {
        // Only try to write as many slices as can be written
        let res = writer
            .write_vectored(slices.get(..1024).unwrap_or(slices))
            .unwrap();
        slices = &slices[(res / 100)..];
    }
}
```
Before this change:
```
write_smart(): 6.666952ms
write_all_vectored(): 498.437092ms
```
After this change:
```
write_smart(): 6.377158ms
write_all_vectored(): 6.923412ms
```

`LineWriter` (and by extension `Stdout`) isn't fully repaired by this because it looks for newlines. I could open an issue for that after this is merged, I think it's fixable but not trivially.
Add  `#[inline]` to `BTreeMap::new` constructor

This PR add the `#[inline]` attribute to `BTreeMap::new` constructor as to make it eligible for inlining.

<details>

For some context: I was profiling `rustc --check-cfg` with callgrind and due to the way we currently setup all the targets and we end-up calling `BTreeMap::new` multiple times for (nearly) all the targets. Adding the `#[inline]` attribute reduced the number of instructions needed.

</details>
…s, r=workingjubilee

PassWrapper: update for llvm/llvm-project@a3319371970b

`@rustbot` label: +llvm-main
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Mar 8, 2024
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=8

@bors
Copy link
Collaborator

bors commented Mar 8, 2024

📌 Commit df4aed1 has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 8, 2024
@bors
Copy link
Collaborator

bors commented Mar 8, 2024

⌛ Testing commit df4aed1 with merge b22d5b9...

bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 8, 2024
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#118623 (Improve std::fs::read_to_string example)
 - rust-lang#119365 (Add asm goto support to `asm!`)
 - rust-lang#120608 (Docs for std::ptr::slice_from_raw_parts)
 - rust-lang#121885 (Move generic `NonZero` `rustc_layout_scalar_valid_range_start` attribute to inner type.)
 - rust-lang#121938 (Fix quadratic behavior of repeated vectored writes)
 - rust-lang#122099 (Add  `#[inline]` to `BTreeMap::new` constructor)
 - rust-lang#122143 (PassWrapper: update for llvm/llvm-project@a3319371970b)

Failed merges:

 - rust-lang#122076 (Tweak the way we protect in-place function arguments in interpreters)

r? `@ghost`
`@rustbot` modify labels: rollup
@rust-log-analyzer
Copy link
Collaborator

The job aarch64-apple failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
Build completed unsuccessfully in 0:29:23

failures:

---- [debuginfo-lldb] tests/debuginfo/numeric-types.rs stdout ----
NOTE: compiletest thinks it is using LLDB version 1403
NOTE: compiletest thinks it is using LLDB without native rust support

error: check directive(s) from `/Users/runner/work/rust/rust/tests/debuginfo/numeric-types.rs` not found in debugger output. errors:
    (numeric-types.rs:206) `[...]$0 = 11 { __0 = 11 }`
    (numeric-types.rs:209) `[...]$1 = 22 { __0 = 22 }`
    (numeric-types.rs:212) `[...]$2 = 33 { __0 = 33 }`
    (numeric-types.rs:215) `[...]$3 = 44 { __0 = 44 }`
    (numeric-types.rs:218) `[...]$4 = 55 { __0 = 55 }`
    (numeric-types.rs:221) `[...]$5 = 66 { __0 = 66 }`
    (numeric-types.rs:224) `[...]$6 = 77 { __0 = 77 }`
    (numeric-types.rs:227) `[...]$7 = 88 { __0 = 88 }`
    (numeric-types.rs:230) `[...]$8 = 99 { __0 = 99 }`
    (numeric-types.rs:233) `[...]$9 = 100 { __0 = 100 }`
    (numeric-types.rs:236) `[...]$10 = 111 { __0 = 111 }`
    (numeric-types.rs:239) `[...]$11 = 122 { __0 = 122 }`
status: exit status: 0
command: PYTHONPATH="/Applications/Xcode_14.3.1.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python" PYTHONUNBUFFERED="1" "/usr/bin/python3" "/Users/runner/work/rust/rust/src/etc/lldb_batchmode.py" "/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/numeric-types.lldb/a" "/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/numeric-types.lldb/numeric-types.debugger.script"
LLDB batch-mode script
----------------------
----------------------
Debugger commands script is '/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/numeric-types.lldb/numeric-types.debugger.script'.
Target executable is '/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/numeric-types.lldb/a'.
Current working directory is '/Users/runner/work/rust/rust'
Creating a target for '/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/numeric-types.lldb/a'
settings set auto-confirm true
version
version
lldb-1403.0.17.67 Apple Swift version 5.8.1 (swiftlang-5.8.0.124.5 clang-1403.0.22.11.100) 
command unalias print
command alias print expr --
command unalias p
command alias p expr --
command script import /Users/runner/work/rust/rust/./src/etc/lldb_lookup.py
type synthetic add -l lldb_lookup.synthetic_lookup -x '.*' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(alloc::([a-z_]+::)+)String$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^&(mut )?str$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^&(mut )?\[.+\]$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(std::ffi::([a-z_]+::)+)OsString$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(alloc::([a-z_]+::)+)Vec<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(alloc::([a-z_]+::)+)VecDeque<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(alloc::([a-z_]+::)+)BTreeSet<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(alloc::([a-z_]+::)+)BTreeMap<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(std::collections::([a-z_]+::)+)HashMap<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(std::collections::([a-z_]+::)+)HashSet<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(alloc::([a-z_]+::)+)Rc<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(alloc::([a-z_]+::)+)Arc<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(core::([a-z_]+::)+)Cell<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(core::([a-z_]+::)+)Ref<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(core::([a-z_]+::)+)RefMut<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^(core::([a-z_]+::)+)RefCell<.+>$' --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h '^core::num::([a-z_]+::)*NonZero.+$' --category Rust
type category enable Rust

breakpoint set --file 'numeric-types.rs' --line 289
DEBUG: breakpoint added, id = 1
Breakpoint 1: where = a`numeric_types::main::hf67f3ccf1c8d9bce + 1236 at numeric-types.rs:289:5, address = 0x00000001000038fc 
DEBUG: registering breakpoint callback, id = 1
Error while trying to register breakpoint callback, id = 1, message = error: could not get num args: can't find callable: breakpoint_callback
run
run
Process 78310 stopped * thread #1, name = 'main', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x00000001000038fc a`numeric_types::main::hf67f3ccf1c8d9bce at numeric-types.rs:289:5 286 let a_u64 = AtomicU64::new(512); 287 let a_usize = AtomicUsize::new(1024); 288 -> 289 zzz(); // #break ^ 290 } 291 292 fn zzz() { } Target 0: (a) stopped. Process 78310 launched: '/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/numeric-types.lldb/a' (arm64) 
print/d nz_i8
(core::num::nonzero::NonZero<char>) $0 = None { __0 = 11 { __0 = 11 } } 
print nz_i16
(core::num::nonzero::NonZero<short>) $1 = None { __0 = 22 { __0 = 22 } } 
print nz_i32
(core::num::nonzero::NonZero<int>) $2 = None { __0 = 33 { __0 = 33 } } 
print nz_i64
(core::num::nonzero::NonZero<long>) $3 = None { __0 = 44 { __0 = 44 } } 
print nz_i128
(core::num::nonzero::NonZero<__int128>) $4 = None { __0 = 55 { __0 = 55 } } 
print nz_isize
$5 = 
print/d nz_u8
(core::num::nonzero::NonZero<unsigned char>) $6 = None { __0 = 77 { __0 = 77 } } 
print nz_u16
(core::num::nonzero::NonZero<unsigned short>) $7 = None { __0 = 88 { __0 = 88 } } 
print nz_u32
(core::num::nonzero::NonZero<unsigned int>) $8 = None { __0 = 99 { __0 = 99 } } 
print nz_u64
(core::num::nonzero::NonZero<unsigned long>) $9 = None { __0 = 100 { __0 = 100 } } 
print nz_u128
(core::num::nonzero::NonZero<unsigned __int128>) $10 = None { __0 = 111 { __0 = 111 } } 
print nz_usize
quit
------------------------------------------
stderr: none

@bors
Copy link
Collaborator

bors commented Mar 8, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 8, 2024
@matthiaskrgr matthiaskrgr deleted the rollup-ozesu25 branch March 16, 2024 18:19
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.