https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=beta 2025-09-12T18:45:12+00:00 2025-09-12T18:45:12+00:00 Oneirical manchot@videotron.ca 2025-08-20T18:02:50+00:00 urn:sha1:957fa10d50787a4c6c6d8a35be5af6bd43ba1770 2025-08-19T19:27:10+00:00 Karol Zwolak karolzwolak7@gmail.com 2025-04-28T11:47:25+00:00 urn:sha1:d14b83e378c421dd09320ace833a9d47848e3046 2025-07-19T16:44:07+00:00 Martin Nordholts martin.nordholts@codetale.se 2025-06-25T05:56:40+00:00 urn:sha1:e1d4f2a0c297690ddfc24815de57539f532f2471 And introduce two new directives for ui tests: * `run-crash` * `run-fail-or-crash` Normally a `run-fail` ui test like tests that panic shall not be terminated by a signal like `SIGABRT`. So begin having that as a hard requirement. Some of our current tests do terminate by a signal/crash however. Introduce and use `run-crash` for those tests. Note that Windows crashes are not handled by signals but by certain high bits set on the process exit code. Example exit code for crash on Windows: `0xc000001d`. Because of this, we define "crash" on all platforms as "not exit with success and not exit with a regular failure code in the range 1..=127". Some tests behave differently on different targets: * Targets without unwind support will abort (crash) instead of exit with failure code 101 after panicking. As a special case, allow crashes for `run-fail` tests for such targets. * Different sanitizer implementations handle detected memory problems differently. Some abort (crash) the process while others exit with failure code 1. Introduce and use `run-fail-or-crash` for such tests. 2025-07-04T19:45:24+00:00 Kivooeo Kivooeo123@gmail.com 2025-07-01T13:24:12+00:00 urn:sha1:b28806da237176468ab2afae42b51fe43ad416e6 2025-07-01T13:21:05+00:00 Kivooeo Kivooeo123@gmail.com 2025-07-01T13:21:05+00:00 urn:sha1:986f1c9b692665d4e7388062b8d8536acb0c99fd 2025-03-19T16:55:02+00:00 Jeff Martin martinjeffrey@google.com 2025-03-19T16:55:02+00:00 urn:sha1:ef815f3205eedec26c715463f51a6793e2fa651f The channel-stack-overflow-issue-102246 regression test fails on platforms with a small default stack size (e.g. Fuchsia, with a default of 256KiB). Update the test to specify an exact stack size for both the sender and receiver operations, to ensure it is platform agnostic. Set the stack size to less than the total allocation size of the mpsc channel, to continue to prove that the allocation is on the heap. 2025-01-23T12:51:29+00:00 许杰友 Jieyou Xu (Joe) 39484203+jieyouxu@users.noreply.github.com 2025-01-23T08:56:11+00:00 urn:sha1:e00e10c943947aa3d6a6bcbdf8ca035e9d8fd865 - Use `needs-threads` instead of `ignore-sgx`. - Remove unnecessary import and `#![allow(unused_import)]`. 2024-11-08T02:18:34+00:00 Josh Stone jistone@redhat.com 2024-11-08T02:18:34+00:00 urn:sha1:9827c6dc2c1b81ec4e30a630e297745341977288 2024-11-07T18:09:45+00:00 Josh Stone jistone@redhat.com 2024-11-07T17:51:52+00:00 urn:sha1:03383ad1021bd0ba34c28d7fda16e634a9ec8df4 The channel's `Block::new` was causing a stack overflow because it held 32 item slots, instantiated on the stack before moving to `Box::new`. The 32x multiplier made modestly-large item sizes untenable. That block is now initialized directly on the heap. Fixes #102246 2024-10-15T12:25:55+00:00 Hood Chatham roberthoodchatham@gmail.com 2024-10-14T19:16:27+00:00 urn:sha1:1d6643c4f69ba31f91a385c51f46d615bd2b0d66 To fix the linker errors, we need to set the output extension to `.js` instead of `.wasm`. Setting the output to a `.wasm` file puts Emscripten into standalone mode which is effectively a distinct target. We need to set the runner to be `node` as well. This fixes most of the ui tests. I fixed a few more tests with simple problems: - `intrinsics/intrinsic-alignment.rs` and `structs-enums/rec-align-u64.rs` -- Two `#[cfg]` macros match for Emscripten so we got a duplicate definition of `mod m`. - `issues/issue-12699.rs` -- Seems to hang so I disabled it - `process/process-sigpipe.rs` -- Not expected to work on Emscripten so I disabled it