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

Try to write the panic message with a single write_all call #122565

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Zoxc
Copy link
Contributor

@Zoxc Zoxc commented Mar 15, 2024

This writes the panic message to a buffer before writing to stderr. This allows it to be printed with a single write_all call, preventing it from being interleaved with other outputs. It also adds newlines before and after the message ensuring that only the panic message will have its own lines.

Before:

thread 'thread 'thread 'thread 'thread '<unnamed>thread 'thread 'thread 'thread '<unnamed><unnamed>thread '<unnamed>' panicked at ' panicked at <unnamed><unnamed><unnamed><unnamed><unnamed>' panicked at <unnamed>' panicked at src\heap.rssrc\heap.rs' 
panicked at ' panicked at ' panicked at ' panicked at ' panicked at src\heap.rs' panicked at src\heap.rs::src\heap.rssrc\heap.rssrc\heap.rssrc\heap.rssrc\heap.rs:src\heap.rs:455455:::::455:455::455455455455455:455:99:::::9:9:
:
999:
999:
assertion failed: size <= (*queue).block_size:
:
assertion failed: size <= (*queue).block_size:
assertion failed: size <= (*queue).block_size:
:
:
assertion failed: size <= (*queue).block_sizeassertion failed: size <= (*queue).block_sizeassertion failed: size <= (*queue).block_size

assertion failed: size <= (*queue).block_size
assertion failed: size <= (*queue).block_sizeassertion failed: size <= (*queue).block_sizeerror: process didn't exit successfully: `target\debug\direct_test.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)

After:


thread '<unnamed>' panicked at src\heap.rs:455:9:
assertion failed: size <= (*queue).block_size


thread '<unnamed>' panicked at src\heap.rs:455:9:
assertion failed: size <= (*queue).block_size


thread '<unnamed>' panicked at src\heap.rs:455:9:
assertion failed: size <= (*queue).block_size

error: process didn't exit successfully: `target\debug\direct_test.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)

@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. labels Mar 15, 2024
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rustbot
Copy link
Collaborator

rustbot commented Mar 16, 2024

The Miri subtree was changed

cc @rust-lang/miri

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

let mut cursor = crate::io::Cursor::new(&mut buffer[..]);

let write_msg = |dst: &mut dyn crate::io::Write| {
writeln!(dst, "\nthread '{name}' panicked at {location}:\n{msg}")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest to separate the functional change (more newlines) from the implementation change. Makes it easier to discuss and decide on these separately.

A leading newline is not very common in Rust output, so if it stays it definitely needs a comment explaining the purpose.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Panic output isn't stable. There's some work to add thread IDs to the panic message for example.

Yeah the extra newline is unusual, but this is an unsynchronized write to a shared output so we don't have many options to clean up the formatting in cases where a panic is emitted in the middle of something else that's printing.

proc_macro_generated_packed.stderr is a good example of this. It start printing the panic message in the middle of reporting another error.

Do you think it's disruptive enough that it warrants separate discussion?

@rustbot
Copy link
Collaborator

rustbot commented Mar 17, 2024

Some changes occurred in run-make tests.

cc @jieyouxu

@bors
Copy link
Contributor

bors commented Apr 2, 2024

☔ The latest upstream changes (presumably #122267) made this pull request unmergeable. Please resolve the merge conflicts.

@correabuscar
Copy link

Would it be possible(or too overkill?) to check how much stack is left(but without using external crate) and if enough only then write to the on-stack buffer, else write to err directly to avoid a stack overflow ?

I sort of tried to look into it, preliminarily, and it seems that (perhaps due to println!? unsure) it needs >=816 bytes left on reported stack or it will stack overflow in this example:
https://github.com/correabuscar/sandbox/blob/9aecdfa0aead32bc37377a07e57030f623aaad7b/rust/05_sandbox/stack/how_much_stack_is_left/src/main.rs#L9

output is like this on linux/gentoo:

     Running `target/debug/how_much_stack_is_left`
Hello, main world! Some(8371024)
Hello, thread world! Some(19664)
Depth: 1, stack left: Some(19344)
Depth: 2, stack left: Some(19024)
...
Depth: 57, stack left: Some(1424)
Depth: 58, stack left: Some(1104)
End=58
From cloj, stack left: Some(816)

@workingjubilee
Copy link
Member

If we reserve a 512 byte buffer on the stack, then we don't have a guarantee that the compiler doesn't emit code that forces using 512 bytes deeper into the stack even on the codepath that does not write to that (as it may do something like, for instance, sub rsp, 512; push rax;).

@the8472 the8472 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 12, 2024
@correabuscar
Copy link

If we reserve a 512 byte buffer on the stack, then we don't have a guarantee that the compiler doesn't emit code that forces using 512 bytes deeper into the stack even on the codepath that does not write to that (as it may do something like, for instance, sub rsp, 512; push rax;).

I'm not sure I understand that ^, which leads me to say this: but isn't the buffer only allocated on the stack if the specific closure gets to execute? assuming the buffer is inside that closure which we wouldn't execute in the case when we'd know there's not enough stack left for it.

@workingjubilee
Copy link
Member

workingjubilee commented May 17, 2024

I'm not sure I understand that ^, which leads me to say this: but isn't the buffer only allocated on the stack if the specific closure gets to execute? assuming the buffer is inside that closure which we wouldn't execute in the case when we'd know there's not enough stack left for it.

Speaking very broadly... please do not take this as a gospel fact in all cases, but rather as more "Jubilee's understanding of the underlying principles at work, as she has derived from experience (and sometimes talking to LLVM devs)"... LLVM does not view itself as beholden to concerns like "have we run out of stack?" when performing optimizations. That means it is basically always valid to hoist constant byte arrays like that to earlier.

That in itself wouldn't mean we allocate a bunch of extra stack always... but by and large, our closures tend to optimize well because they are inlined into the function that calls them, which means that the enclosing function and the closure are optimized together into a single call. We have to apply many annotations to discourage this behavior.

This doesn't mean LLVM loves optimizing byte arrays on the stack so much it will always do this, it's just that when it's about, like... 512 bytes? I don't think checking if we have 512 bytes available is worth the other costs.

@workingjubilee
Copy link
Member

on a less "what are legal program optimizations?" level: in general the stack is chunked into pages of 4KB or more, so using stacker to check for less than 4kb left of stack is... a little silly.

@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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 22, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Sep 22, 2024
Try to write the panic message with a single `write_all` call

This writes the panic message to a buffer before writing to stderr. This allows it to be printed with a single `write_all` call, preventing it from being interleaved with other outputs. It also adds newlines before and after the message ensuring that only the panic message will have its own lines.

Before:
```
thread 'thread 'thread 'thread 'thread '<unnamed>thread 'thread 'thread 'thread '<unnamed><unnamed>thread '<unnamed>' panicked at ' panicked at <unnamed><unnamed><unnamed><unnamed><unnamed>' panicked at <unnamed>' panicked at src\heap.rssrc\heap.rs'
panicked at ' panicked at ' panicked at ' panicked at ' panicked at src\heap.rs' panicked at src\heap.rs::src\heap.rssrc\heap.rssrc\heap.rssrc\heap.rssrc\heap.rs:src\heap.rs:455455:::::455:455::455455455455455:455:99:::::9:9:
:
999:
999:
assertion failed: size <= (*queue).block_size:
:
assertion failed: size <= (*queue).block_size:
assertion failed: size <= (*queue).block_size:
:
:
assertion failed: size <= (*queue).block_sizeassertion failed: size <= (*queue).block_sizeassertion failed: size <= (*queue).block_size

assertion failed: size <= (*queue).block_size
assertion failed: size <= (*queue).block_sizeassertion failed: size <= (*queue).block_sizeerror: process didn't exit successfully: `target\debug\direct_test.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)
```
After:
```

thread '<unnamed>' panicked at src\heap.rs:455:9:
assertion failed: size <= (*queue).block_size

thread '<unnamed>' panicked at src\heap.rs:455:9:
assertion failed: size <= (*queue).block_size

thread '<unnamed>' panicked at src\heap.rs:455:9:
assertion failed: size <= (*queue).block_size

error: process didn't exit successfully: `target\debug\direct_test.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)
```

r? `@the8472`
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 22, 2024
…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#122565 (Try to write the panic message with a single `write_all` call)
 - rust-lang#129550 (Add str.as_str() for easy Deref to string slices)
 - rust-lang#130659 (Support `char::encode_utf16` in const scenarios.)
 - rust-lang#130705 (No longer mark RTN as incomplete)
 - rust-lang#130712 (Don't call `ty::Const::normalize` in error reporting)
 - rust-lang#130713 (Mark `u8::make_ascii_uppercase` and `u8::make_ascii_lowercase` as const.)
 - rust-lang#130714 (Introduce `structurally_normalize_const`, use it in `rustc_hir_typeck`)
 - rust-lang#130715 (Replace calls to `ty::Const::{try_}eval` in mir build/pattern analysis)

r? `@ghost`
`@rustbot` modify labels: rollup
@workingjubilee
Copy link
Member

@bors r-
@bors try

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 22, 2024
@bors
Copy link
Contributor

bors commented Sep 22, 2024

⌛ Trying commit 86fc657 with merge 16b95fb...

bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 22, 2024
Try to write the panic message with a single `write_all` call

This writes the panic message to a buffer before writing to stderr. This allows it to be printed with a single `write_all` call, preventing it from being interleaved with other outputs. It also adds newlines before and after the message ensuring that only the panic message will have its own lines.

Before:
```
thread 'thread 'thread 'thread 'thread '<unnamed>thread 'thread 'thread 'thread '<unnamed><unnamed>thread '<unnamed>' panicked at ' panicked at <unnamed><unnamed><unnamed><unnamed><unnamed>' panicked at <unnamed>' panicked at src\heap.rssrc\heap.rs'
panicked at ' panicked at ' panicked at ' panicked at ' panicked at src\heap.rs' panicked at src\heap.rs::src\heap.rssrc\heap.rssrc\heap.rssrc\heap.rssrc\heap.rs:src\heap.rs:455455:::::455:455::455455455455455:455:99:::::9:9:
:
999:
999:
assertion failed: size <= (*queue).block_size:
:
assertion failed: size <= (*queue).block_size:
assertion failed: size <= (*queue).block_size:
:
:
assertion failed: size <= (*queue).block_sizeassertion failed: size <= (*queue).block_sizeassertion failed: size <= (*queue).block_size

assertion failed: size <= (*queue).block_size
assertion failed: size <= (*queue).block_sizeassertion failed: size <= (*queue).block_sizeerror: process didn't exit successfully: `target\debug\direct_test.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)
```
After:
```

thread '<unnamed>' panicked at src\heap.rs:455:9:
assertion failed: size <= (*queue).block_size

thread '<unnamed>' panicked at src\heap.rs:455:9:
assertion failed: size <= (*queue).block_size

thread '<unnamed>' panicked at src\heap.rs:455:9:
assertion failed: size <= (*queue).block_size

error: process didn't exit successfully: `target\debug\direct_test.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)
```

r? `@the8472`

try-job: x86_64-gnu-aux
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-aux failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
file:.git/config remote.origin.url=https://github.com/rust-lang-ci/rust
file:.git/config remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
file:.git/config gc.auto=0
file:.git/config http.https://github.com/.extraheader=AUTHORIZATION: basic ***
file:.git/config branch.try.remote=origin
file:.git/config branch.try.merge=refs/heads/try
file:.git/config submodule.library/backtrace.url=https://github.com/rust-lang/backtrace-rs.git
file:.git/config submodule.library/stdarch.active=true
file:.git/config submodule.library/stdarch.url=https://github.com/rust-lang/stdarch.git
file:.git/config submodule.src/doc/book.active=true

@bors
Copy link
Contributor

bors commented Sep 22, 2024

💔 Test failed - checks-actions

@workingjubilee
Copy link
Member

The actual issue is in the cargo tests:


failures:

---- freshness::dirty_both_lib_and_test stdout ----
running `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/cargo build`
running `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/cargo test --lib`

thread 'freshness::dirty_both_lib_and_test' panicked at tests/testsuite/freshness.rs:1908:10:

---- expected: tests/testsuite/freshness.rs:1886:27
++++ actual:   stdout
   1    1 | 
   2    2 | running 1 test
   3    3 | test t1 ... FAILED
   4    4 | 
   5    5 | failures:
   6    6 | 
   7    7 | ---- t1 stdout ----
        8 + 
   8    9 | thread 't1' panicked at src/lib.rs:8:21:
   9   10 | assertion `left == right` failed: doit assert failure
  10   11 |   left: 2
  11   12 |  right: 1
  12   13 | [NOTE] run with `RUST_BACKTRACE=1` environment variable to display a backtrace
  13   14 | 
  14   15 | 
  15   16 | failures:
  16   17 |     t1
  17   18 | 
  18   19 | test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in [ELAPSED]s
  19   20 | 

Update with SNAPSHOTS=overwrite


---- freshness::script_fails_stay_dirty stdout ----
running `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/cargo build`
running `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/cargo build`

thread 'freshness::script_fails_stay_dirty' panicked at tests/testsuite/freshness.rs:1967:10:

---- expected: tests/testsuite/freshness.rs:1951:27
++++ actual:   stderr
   1    1 | [COMPILING] foo v0.0.1 ([ROOT]/foo)
   2    2 | [ERROR] failed to run custom build command for `foo v0.0.1 ([ROOT]/foo)`
   3    3 | 
   4    4 | Caused by:
   5    5 |   process didn't exit successfully: `[ROOT]/foo/target/debug/build/foo-[HASH]/build-script-build` ([EXIT_STATUS]: 101)
   6    6 |   --- stdout
   7    7 |   cargo::rerun-if-changed=build.rs
   8    8 | 
   9    9 |   --- stderr
       10 + 
  10   11 |   thread 'main' panicked at helper.rs:1:16:
  11   12 |   Crash!
  12   13 |   [NOTE] run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Update with SNAPSHOTS=overwrite


---- install::reports_unsuccessful_subcommand_result stdout ----
running `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/cargo install cargo-fail`
running `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/cargo --list`
running `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/cargo fail`

thread 'install::reports_unsuccessful_subcommand_result' panicked at tests/testsuite/install.rs:1335:10:

---- expected: tests/testsuite/install.rs:1329:27
++++ actual:   stderr
        1 + 
   1    2 | thread 'main' panicked at [ROOT]/home/.cargo/registry/src/-[HASH]/cargo-fail-1.0.0/src/main.rs:1:13:
   2    3 | explicit panic
   3    4 | [NOTE] run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Update with SNAPSHOTS=overwrite


---- jobserver::runner_inherits_jobserver stdout ----
running `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/cargo install --path .`
running `make run -j2`
running `make run-runner -j2`
running `make test -j2`
running `make test-runner -j2`
running `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/cargo run -j2`

thread 'jobserver::runner_inherits_jobserver' panicked at tests/testsuite/jobserver.rs:241:10:

---- expected: tests/testsuite/jobserver.rs:232:27
++++ actual:   stderr
   1    1 | [FINISHED] `dev` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s
   2    2 | [RUNNING] `target/debug/cargo-jobserver-check[EXE]`
        3 + 
   3    4 | thread 'main' panicked at src/main.rs:5:43:
   4    5 | no jobserver from env: NotPresent
   5      - [NOTE] run with `RUST_BACKTRACE=1` environment variable to display a backtrace
   6    6 | ...

Update with SNAPSHOTS=overwrite


---- test::cargo_test_failing_test_in_lib stdout ----
running `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/cargo test`

thread 'test::cargo_test_failing_test_in_lib' panicked at tests/testsuite/test.rs:527:10:

---- expected: tests/testsuite/test.rs:512:27
++++ actual:   stdout
   1    1 | ...
   2    2 | test test_hello ... FAILED
   3    3 | 
   4    4 | failures:
   5    5 | 
   6    6 | ---- test_hello stdout ----
        7 + 
   7    8 | thread 'test_hello' panicked at src/lib.rs:1:27:
   8      - assertion failed: false
   9    9 | ...
  10   10 | failures:
  11   11 |     test_hello
  12   12 | ...∅

Update with SNAPSHOTS=overwrite



failures:
    freshness::dirty_both_lib_and_test
    freshness::script_fails_stay_dirty
    install::reports_unsuccessful_subcommand_result
    jobserver::runner_inherits_jobserver
    test::cargo_test_failing_test_in_lib

test result: FAILED. 3293 passed; 5 failed; 196 ignored; 0 measured; 0 filtered out; finished in 259.53s

@workingjubilee
Copy link
Member

@bors rollup=iffy

@Zoxc
Copy link
Contributor Author

Zoxc commented Sep 23, 2024

It looks like Cargo has some new tests since #112849.

@weihanglo I assume these can be relaxed similarly to rust-lang/cargo#12413?

@weihanglo
Copy link
Member

If it is a change about to land, yes.

@Zoxc
Copy link
Contributor Author

Zoxc commented Sep 26, 2024

@weihanglo Would you mind making those changes? This is just blocking on Cargo atm.

weihanglo added a commit to weihanglo/cargo that referenced this pull request Sep 26, 2024
rust-lang/rust#122565 adds a new line to thread panic output.
To make the current test suites works on stable, beta, and nightly,
this relaxes the assertion around that by globbing everything.
weihanglo added a commit to weihanglo/cargo that referenced this pull request Sep 26, 2024
rust-lang/rust#122565 adds a new line to thread panic output.
To make the current test suites works on stable, beta, and nightly,
this relaxes the assertion around that by globbing everything.
@weihanglo
Copy link
Member

Thought somebody will post a PR instead 😆.

Anyhow, I have just opened one: rust-lang/cargo#14602.

bors added a commit to rust-lang/cargo that referenced this pull request Sep 26, 2024
test: relax panic output assertion

### What does this PR try to resolve?

rust-lang/rust#122565 adds a new line to thread panic output. To make the current test suites works on stable, beta, and nightly, this relaxes the assertion around that by globbing everything.

### How should we test and review this PR?

Switch to rust-lang/rust#122565 and build a stage0 std, then use it to run these Cargo tests.

Linking to stage0 toolchain should work: https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html#creating-a-rustup-toolchain
@Zoxc
Copy link
Contributor Author

Zoxc commented Sep 28, 2024

This could use another try run now.

@the8472
Copy link
Member

the8472 commented Sep 28, 2024

@bors try

@bors
Copy link
Contributor

bors commented Sep 28, 2024

⌛ Trying commit 86fc657 with merge 09d4459...

bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 28, 2024
Try to write the panic message with a single `write_all` call

This writes the panic message to a buffer before writing to stderr. This allows it to be printed with a single `write_all` call, preventing it from being interleaved with other outputs. It also adds newlines before and after the message ensuring that only the panic message will have its own lines.

Before:
```
thread 'thread 'thread 'thread 'thread '<unnamed>thread 'thread 'thread 'thread '<unnamed><unnamed>thread '<unnamed>' panicked at ' panicked at <unnamed><unnamed><unnamed><unnamed><unnamed>' panicked at <unnamed>' panicked at src\heap.rssrc\heap.rs'
panicked at ' panicked at ' panicked at ' panicked at ' panicked at src\heap.rs' panicked at src\heap.rs::src\heap.rssrc\heap.rssrc\heap.rssrc\heap.rssrc\heap.rs:src\heap.rs:455455:::::455:455::455455455455455:455:99:::::9:9:
:
999:
999:
assertion failed: size <= (*queue).block_size:
:
assertion failed: size <= (*queue).block_size:
assertion failed: size <= (*queue).block_size:
:
:
assertion failed: size <= (*queue).block_sizeassertion failed: size <= (*queue).block_sizeassertion failed: size <= (*queue).block_size

assertion failed: size <= (*queue).block_size
assertion failed: size <= (*queue).block_sizeassertion failed: size <= (*queue).block_sizeerror: process didn't exit successfully: `target\debug\direct_test.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)
```
After:
```

thread '<unnamed>' panicked at src\heap.rs:455:9:
assertion failed: size <= (*queue).block_size

thread '<unnamed>' panicked at src\heap.rs:455:9:
assertion failed: size <= (*queue).block_size

thread '<unnamed>' panicked at src\heap.rs:455:9:
assertion failed: size <= (*queue).block_size

error: process didn't exit successfully: `target\debug\direct_test.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)
```

r? `@the8472`

try-job: x86_64-gnu-aux
@bors
Copy link
Contributor

bors commented Sep 29, 2024

☀️ Try build successful - checks-actions
Build commit: 09d4459 (09d4459cbf2d34ce7fe65d6c3d49f89354b26fe0)

@Zoxc
Copy link
Contributor Author

Zoxc commented Oct 7, 2024

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-run-make Area: port run-make Makefiles to rmake.rs 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
Status: In progress
Development

Successfully merging this pull request may close these issues.

10 participants