Skip to content
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 7 pull requests #122176

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
Contributor

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
Contributor

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
Contributor

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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.

None yet