-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 5 pull requests #131869
Rollup of 5 pull requests #131869
Conversation
The recent changes to naked `asm!()` macros made this unbuildable on Xous. The upstream package maintainer released 0.2.3 to fix support on newer nightly toolchains. Update the dependency to 0.2.3, which is the oldest version that works with the current nightly compiler. This closes rust-lang#131602 and fixes the build on xous. Signed-off-by: Sean Cross <[email protected]>
Process arguments and environment variables are both passed by way of Application Parameters. These are a TLV format that gets passed in as the second process argument. This patch combines both as they are very similar in their decode. Signed-off-by: Sean Cross <[email protected]>
Signed-off-by: Sean Cross <[email protected]>
The AdjustProcessLimit syscall was using the correct call number. Signed-off-by: Sean Cross <[email protected]>
The allocator on Xous is now throwing warnings because the allocator needs to be mutable, and allocators hand out mutable pointers, which the `static_mut_refs` lint now catches. Give the same treatment to Xous as wasm, at least until a solution is devised for fixing the warning on wasm. Signed-off-by: Sean Cross <[email protected]>
This was added in cc3c8bb when it was closer to the `extract_one` call. Move it back near that call.
the line was missing closing parenthesis
…=thomcc Various fixes for Xous This patchset includes several fixes for Xous that have crept in over the last few months: * The `adjust_process()` syscall was incorrect * Warnings have started appearing in `alloc` -- adopt the same approach as wasm, until wasm figures out a workaround * Dead code warnings have appeared in the networking code. Add `allow(dead_code)` as these structs are used as IPC values * Add support for `args` and `env`, which have been useful for running tests * Update `unwinding` to `0.2.3` which fixes the recent regression due to changes in `asm!()` code
…dy, r=lcnr rustc_metadata: minor tidying Cleaned up some code while investigating rust-lang#131720. See individual commits.
…kingjubilee Bump libc to 0.2.161 Bumps libc to the latest release version 0.2.161 which - includes libc support for the tier 3 RTEMS target - fixes segfaults on 32-bit FreeBSD targets - gets musl's `posix_spawn_file_actions_addchdir_np` for some spawn opts
Missing parenthesis the line was missing closing parenthesis
… r=compiler-errors Allow dropping dyn principal Revival of rust-lang#126660, which was a revival of rust-lang#114679. Fixes rust-lang#126313. Allows dropping principal when coercing trait objects, e.g. `dyn Debug + Send` -> `dyn Send`. cc `@compiler-errors` `@Jules-Bertholet` r? `@lcnr`
@bors r+ rollup=never p=5 |
See #131867 — my suspicion is the |
@jhpratt that's one of the msvc spurious failures, i.e. #127883. I started to tag the PRs that fail like #127883 with
CI-spurious-fail-msvc
|
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: d9c4b8d475 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Thanks for the info. I'll be sure to simply |
Finished benchmarking commit (db8043b): comparison URL. Overall result: ❌ regressions - 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 (primary 3.2%, secondary 2.1%)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.
CyclesResults (secondary -7.9%)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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 779.34s -> 781.028s (0.22%) |
Successful merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup