-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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 8 pull requests #138448
Rollup of 8 pull requests #138448
Conversation
Co-authored-by: Thalia Archibald <[email protected]>
Unclear why this needs to be done manually and is not done by the existing Trusty patches.
also add test with `fastcall`, which on i686 uses a different mangling scheme
When migrating the standard library to 2024, there will be some behavior changes that users will be able to observe. This test should cover that (I cannot think of any other observable differences).
Co-authored-by: bjorn3 <[email protected]>
We can create the expected error manually, rather than trying to produce a real one, so the error conversion test can run on all targets. Before, it was only running on 64-bit and not miri. In Fedora, we also found that s390x was not getting the expected error, "successfully" allocating the huge size because it was optimizing the real `malloc` call away. It's possible to counter that by looking at the pointer in any way, like a debug print, but it's more robust to just deal with errors directly, since this test is only about conversion.
It reinterprets uninitialized memory as initialized and does not drop existing elements of the Vec. Fix that. Additionally, make it more general by appending, instead of overwriting existing elements, and rename it to `append_to_enclave_vec`. A caller can simply call `.clear()` before, for the old behavior.
Signed-off-by: onur-ozkan <[email protected]>
Signed-off-by: onur-ozkan <[email protected]>
Simulate OOM for the `try_oom_error` test We can create the expected error manually, rather than trying to produce a real one, so the error conversion test can run on all targets. Before, it was only running on 64-bit and not miri. In Fedora, we also found that s390x was not getting the expected error, "successfully" allocating the huge size because it was optimizing the real `malloc` call away. It's possible to counter that by looking at the pointer in any way, like a debug print, but it's more robust to just deal with errors directly, since this test is only about conversion. Related: rust-lang#133806
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
Post-merge analysis result Test differences
(and 15 additional diffs) |
📌 Perf builds for each rolled up PR:
previous master: 961351c76c In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (a2aba05): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (secondary -2.4%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeResults (primary -0.1%, secondary -0.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 777.245s -> 775.375s (-0.24%) |
Successful merges:
rls
#126856 (remove deprecated toolrls
)read_buf
and vectored read/write for SGX stdio #137355 (Implementread_buf
and vectored read/write for SGX stdio).endef
without the symbol name #138346 (naked functions: on windows emit.endef
without the symbol name)try_oom_error
test #138370 (Simulate OOM for thetry_oom_error
test)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup