Rollup of 5 pull requests #127941
Closed
Rollup of 5 pull requests #127941
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
Use a custom simple_text_output protocol to capture output. Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
Implement stderr support in similar fashion. Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
Only tested in 2 levels right now. Need args support for 3 levels Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
Also fix stdio inherit Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
- Update system table crc32 - Fix unsound use of Box - Free exit data - Code improvements - Introduce OwnedTable - Update r-efi to latest version - Use extended_varargs_abi_support for install_multiple_protocol_interfaces and uninstall_multiple_protocol_interfaces - Fix comments - Stub out args implementation Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
In <rust-lang#126922>, the `binary_asm_labels` lint was added which flags labels such as `0:` and `1:`. Before that change, LLVM was giving a confusing error on x86/x86_64 because of an incorrect interpretation. However, targets other than x86 and x86_64 never had the error message and have not been a problem. This means that the lint was causing code that previously worked to start failing (e.g. `compiler_builtins`), rather than only providing a more clear messages where there has always been an error. Adjust the lint to only fire on x86 and x86_64 assembly to avoid this regression.
The link pointed to a closed issue. Create a new one and point the link to it. Also add a help message to hint what change the user could make. Fixes: rust-lang#127821
…ethercote Handle .init_array link_section specially on wasm Given that wasm-ld now has support for [.init_array](https://github.com/llvm/llvm-project/blob/8f2bd8ae68883592a333f4bdbed9798d66e68630/llvm/lib/MC/WasmObjectWriter.cpp#L1852), it appears we can easily implement that section by falling through to the normal path rather than taking the typical custom_section path for wasm. The wasm-ld appears to have a bunch of limitations. Only one static with the `link_section` in a crate or else you hit the fatal error in the link above "only one .init_array section fragment supported". They do not get merged. You can still call multiple constructors by setting it to an array. ``` unsafe extern "C" fn ctor() { println!("foo"); } #[used] #[link_section = ".init_array"] static FOO: [unsafe extern "C" fn(); 2] = [ctor, ctor]; ``` Another issue appears to be that if crate *A* depends on crate *B*, but *A* doesn't call any symbols from *B* and *B* doesn't `#[export_name = ...]` any symbols, then crate *B*'s constructor will not be called. The workaround to this is to provide an exported symbol in crate *B*.
Add Process support for UEFI UEFI does not have an actual process. However, it does provide methods to launch and execute another UEFI image. Having process support is important since it is possible to run rust test suit using `Command::output` and is the first step towards being able to run it for UEFI. Here is an overview of how the support is implemented. - We create a copy of the SystemTable. This is required since at least OVMF seems to crash if the original system table is modified. - Stdout and Stderr pipe works by registering a new `simple_text_output` Protocol and pointing the child system table to use those. - `Stdio::Inherit` just points the console to the current running image console which seems to work with even 3 levels of process. - `spawn` is left unimplemented since it does not make sense for UEFI architecture. Additionally, since rust-lang#105458 was merged, the `spawn` and `output` implementations are completely independent.
Rewrite and rename `issue-22131` and `issue-26006` `run-make` tests to rmake Part of rust-lang#121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html). Please try: try-job: x86_64-msvc try-job: i686-mingw
…bzol Migrate `lto-smoke-c` and `link-path-order` `run-make` tests to rmake Part of rust-lang#121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
…y, r=estebank Change `binary_asm_labels` to only fire on x86 and x86_64 In <rust-lang#126922>, the `binary_asm_labels` lint was added which flags labels such as `0:` and `1:`. Before that change, LLVM was giving a confusing error on x86/x86_64 because of an incorrect interpretation. However, targets other than x86 and x86_64 never had the error message and have not been a problem. This means that the lint was causing code that previously worked to start failing (e.g. `compiler_builtins`), rather than only providing a more clear messages where there has always been an error. Adjust the lint to only fire on x86 and x86_64 assembly to avoid this regression. Also update the help message. Fixes: rust-lang#127821
rustbot
added
A-run-make
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jul 19, 2024
…llaumeGomez Rollup of 5 pull requests Successful merges: - rust-lang#121533 (Handle .init_array link_section specially on wasm) - rust-lang#123196 (Add Process support for UEFI) - rust-lang#127621 (Rewrite and rename `issue-22131` and `issue-26006` `run-make` tests to rmake) - rust-lang#127928 (Migrate `lto-smoke-c` and `link-path-order` `run-make` tests to rmake) - rust-lang#127935 (Change `binary_asm_labels` to only fire on x86 and x86_64) r? `@ghost` `@rustbot` modify labels: rollup
|
Something weird with bors https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Bors.20wants.20vacation @bors treeclosed=100 |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jul 19, 2024
…llaumeGomez Rollup of 5 pull requests Successful merges: - rust-lang#121533 (Handle .init_array link_section specially on wasm) - rust-lang#123196 (Add Process support for UEFI) - rust-lang#127621 (Rewrite and rename `issue-22131` and `issue-26006` `run-make` tests to rmake) - rust-lang#127928 (Migrate `lto-smoke-c` and `link-path-order` `run-make` tests to rmake) - rust-lang#127935 (Change `binary_asm_labels` to only fire on x86 and x86_64) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
issue-22131andissue-26006run-maketests to rmake #127621 (Rewrite and renameissue-22131andissue-26006run-maketests to rmake)lto-smoke-candlink-path-orderrun-maketests to rmake #127928 (Migratelto-smoke-candlink-path-orderrun-maketests to rmake)binary_asm_labelsto only fire on x86 and x86_64 #127935 (Changebinary_asm_labelsto only fire on x86 and x86_64)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup