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 6 pull requests #124697

Closed
wants to merge 16 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

joboet and others added 16 commits April 2, 2024 11:41
…to preserve all UB that the native intrinsic would have
…nton

Reduce code size of `thread::set_current`

rust-lang#123265 introduced a rather large binary size regression, because it added an `unwrap()` call on a `Result<(), Thread>`, which in turn pulled its rather heavy `Debug` implementation. This PR fixes this by readding the `rtassert!` that was removed.
…ChrisDenton

Move thread parking to `sys::sync`

Part of rust-lang#117276.

I'll leave the platform-specific API abstractions in `sys::pal`, as per the initial proposal. I'm not entirely sure whether we'll want to keep it that way, but that remains to be seen.

r? `@ChrisDenton` (if you have time)
…dy, r=RalfJung

Let miri and const eval execute intrinsics' fallback bodies

fixes rust-lang/miri#3397

r? `@RalfJung`
…, r=Mark-Simulacrum

lldb-formatters: Use StdSliceSyntheticProvider for &str

&str has associated summary provider which correctly displays string values in debugger, but while working on rust-lang#124458 I've noticed that a &str inside an enum displays a blob of memory until a 0 is reached (as a c-string) which makes a very bizarre experience when debugging

However there is already StdSliceSyntheticProvider which we use for other slices. This PR enables the same synthetic provider to be used for &str, however the summary provider is still fixed to return the string value

I've added a test `debuginfo/strings-and-strs.rs` which prior to this PR would output the following in LLDB:
```
* thread #1, name = 'a', stop reason = breakpoint 1.1
    frame #0: 0x0000555555556383 a`strings_and_strs::main::h1d2b5f9227b8767d at strings-and-strs.rs:47:5
   44  	    let plain_str = "Hello";
   45  	    let str_in_struct = Foo { inner: "Hello" };
   46  	    let str_in_tuple = ("Hello", "World");
-> 47  	    zzz(); // #break
   48  	}
   49
   50  	fn zzz() {
(lldb) frame var
(alloc::string::String) plain_string = "Hello" {
  vec = size=5 {
    [0] = 'H'
    [1] = 'e'
    [2] = 'l'
    [3] = 'l'
    [4] = 'o'
  }
}
(&str) plain_str = "Hello" {
  data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py"
  length = 5
}
(strings_and_strs::Foo) str_in_struct = {
  inner = "Hello" {
    data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py"
    length = 5
  }
}
((&str, &str)) str_in_tuple = {
  0 = "Hello" {
    data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py"
    length = 5
  }
  1 = "World" {
    data_ptr = 0x0000555555557268 "World\U00000001gdb_load_rust_pretty_printers.py"
    length = 5
  }
}
```
After this PR it would look the following way:

```
* thread #1, name = 'a', stop reason = breakpoint 1.1
    frame #0: 0x0000555555556383 a`strings_and_strs::main::h1d2b5f9227b8767d at strings-and-strs.rs:47:5
   44  	    let plain_str = "Hello";
   45  	    let str_in_struct = Foo { inner: "Hello" };
   46  	    let str_in_tuple = ("Hello", "World");
-> 47  	    zzz(); // #break
   48  	}
   49
   50  	fn zzz() {
(lldb) frame var
(alloc::string::String) plain_string = "Hello" {
  vec = size=5 {
    [0] = 'H'
    [1] = 'e'
    [2] = 'l'
    [3] = 'l'
    [4] = 'o'
  }
}
(&str) plain_str = "Hello" {
  [0] = 'H'
  [1] = 'e'
  [2] = 'l'
  [3] = 'l'
  [4] = 'o'
}
(strings_and_strs::Foo) str_in_struct = {
  inner = "Hello" {
    [0] = 'H'
    [1] = 'e'
    [2] = 'l'
    [3] = 'l'
    [4] = 'o'
  }
}
((&str, &str)) str_in_tuple = {
  0 = "Hello" {
    [0] = 'H'
    [1] = 'e'
    [2] = 'l'
    [3] = 'l'
    [4] = 'o'
  }
  1 = "World" {
    [0] = 'W'
    [1] = 'o'
    [2] = 'r'
    [3] = 'l'
    [4] = 'd'
  }
}
```
…r, r=tmandry

Set non-leaf frame pointers on Fuchsia targets

This is part of our work to enable shadow call stack sanitization on Fuchsia, see [this Fuchsia issue](https://g-issues.fuchsia.dev/issues/327643884).

r? `@tmandry`
…pointer-coercion-happens, r=compiler-errors

We do not coerce `&mut &mut T -> *mut mut T`

Resolves rust-lang#34117 by declaring it to be "working as intended" until someone RFCs it or whatever other lang proposal would be required. It seems a bit of a footgun, but perhaps there are strong reasons to allow it anyways. Seeing as how I often have to be mindful to not allow a pointer to coerce the wrong way in my FFI work, I am inclined to think not, but perhaps it's fine in some use-case and that's actually more common?
@rustbot rustbot added O-SGX Target: SGX O-unix Operating system: Unix-like O-wasi Operating system: Wasi, Webassembly System Interface O-wasm Target: WASM (WebAssembly), http://webassembly.org/ O-windows Operating system: Windows 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 May 4, 2024
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=6

@bors
Copy link
Contributor

bors commented May 4, 2024

📌 Commit e82ed82 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 May 4, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request May 4, 2024
…iaskrgr

Rollup of 6 pull requests

Successful merges:

 - rust-lang#123356 (Reduce code size of `thread::set_current`)
 - rust-lang#124159 (Move thread parking to `sys::sync`)
 - rust-lang#124293 (Let miri and const eval execute intrinsics' fallback bodies)
 - rust-lang#124500 (lldb-formatters: Use StdSliceSyntheticProvider for &str)
 - rust-lang#124677 (Set non-leaf frame pointers on Fuchsia targets)
 - rust-lang#124692 (We do not coerce `&mut &mut T -> *mut mut T`)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors
Copy link
Contributor

bors commented May 4, 2024

⌛ Testing commit e82ed82 with merge e2870a1...

@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)
test [debuginfo-lldb] tests/debuginfo/vec.rs ... ok

failures:

---- [debuginfo-lldb] tests/debuginfo/empty-string.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/empty-string.rs` not found in debugger output. errors:
    (empty-string.rs:26) `[...] empty_str = "" { data_ptr = [...] length = 0 }`
the following subset of check directive(s) was found successfully:
    (empty-string.rs:23) `(alloc::string::String) empty_string = "" { vec = size=0 } `
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/empty-string.lldb/a" "/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/empty-string.lldb/empty-string.debugger.script"
LLDB batch-mode script
----------------------
----------------------
Debugger commands script is '/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/empty-string.lldb/empty-string.debugger.script'.
Target executable is '/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/empty-string.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/empty-string.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 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::([a-z_]+::)+)NonZero<.+>$" --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h "^core::num::([a-z_]+::)*NonZero.+$" --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(std::([a-z_]+::)+)PathBuf$" --category Rust
type summary add -F lldb_lookup.summary_lookup  -e -x -h "^&(mut )?(std::([a-z_]+::)+)Path$" --category Rust
type category enable Rust

breakpoint set --file 'empty-string.rs' --line 33
DEBUG: breakpoint added, id = 1
Breakpoint 1: where = a`empty_string::main::h2256f1a6a0fbd344 + 32 at empty-string.rs:33:5, address = 0x0000000100003aa0 
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 90782 stopped * thread #1, name = 'main', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0000000100003aa0 a`empty_string::main::h2256f1a6a0fbd344 at empty-string.rs:33:5 30 31 let empty_str = ""; 32 -> 33 zzz(); // #break ^ 34 } 35 36 fn zzz() {} Target 0: (a) stopped. Process 90782 launched: '/Users/runner/work/rust/rust/build/aarch64-apple-darwin/test/debuginfo/empty-string.lldb/a' (arm64) 
fr v empty_string
(alloc::string::String) empty_string = "" { vec = size=0 } 
fr v empty_str
(&str) empty_str = "" 
------------------------------------------
stderr: none


@bors
Copy link
Contributor

bors commented May 4, 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 May 4, 2024
@matthiaskrgr matthiaskrgr deleted the rollup-mem7se5 branch September 1, 2024 17:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-SGX Target: SGX O-unix Operating system: Unix-like O-wasi Operating system: Wasi, Webassembly System Interface O-wasm Target: WASM (WebAssembly), http://webassembly.org/ O-windows Operating system: Windows 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.

8 participants