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

Rollup of 5 pull requests #127941

Closed
wants to merge 22 commits into from

Conversation

GuillaumeGomez
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

ratmice and others added 22 commits February 23, 2024 17:47
Signed-off-by: Ayush Singh <[email protected]>
Use a custom simple_text_output protocol to capture output.

Signed-off-by: Ayush Singh <[email protected]>
Implement stderr support in similar fashion.

Signed-off-by: Ayush Singh <[email protected]>
Only tested in 2 levels right now. Need args support for 3 levels

Signed-off-by: Ayush Singh <[email protected]>
Also fix stdio inherit

Signed-off-by: Ayush Singh <[email protected]>
- 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 <[email protected]>
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 rustbot added A-run-make Area: port run-make Makefiles to rmake.rs A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) 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. rollup A PR which is a rollup labels Jul 18, 2024
@GuillaumeGomez
Copy link
Member Author

Follow-up of #127936.

@bors r+ p=5 rollup=never

@bors
Copy link
Contributor

bors commented Jul 18, 2024

📌 Commit fb751e0 has been approved by GuillaumeGomez

It is now in the queue for this repository.

@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-review Status: Awaiting review from the assignee but also interested parties. labels Jul 18, 2024
@bors
Copy link
Contributor

bors commented Jul 19, 2024

⌛ Testing commit fb751e0 with merge 0cb871d...

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
@tgross35
Copy link
Contributor

@bors
Copy link
Contributor

bors commented Jul 19, 2024

⌛ Testing commit fb751e0 with merge 011c2fc...

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
@rust-log-analyzer
Copy link
Collaborator

The job aarch64-apple failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[TIMING] core::build_steps::tool::LintDocs { compiler: Compiler { stage: 0, host: aarch64-apple-darwin }, target: aarch64-apple-darwin } -- 0.000
##[group]Running stage2 lint-docs (aarch64-apple-darwin)
warning: the code example in lint `binary_asm_labels` in /Users/runner/work/rust/rust/compiler/rustc_lint/src/builtin.rs failed to generate the expected output: did not find lint `binary_asm_labels` in output of example, got:

error: unrecognized instruction mnemonic, did you mean: cmp?
  |
  |
6 |         asm!("0: jmp 0b");
  |
note: instantiated into assembly here
note: instantiated into assembly here
 --> <inline asm>:1:5
1 |     0: jmp 0b
  |        ^


---
Generating lint docs (aarch64-apple-darwin)
##[group]Running stage2 lint-docs (aarch64-apple-darwin)
error: failed to test example in lint docs for `binary_asm_labels` in /Users/runner/work/rust/rust/compiler/rustc_lint/src/builtin.rs:2737: did not find lint `binary_asm_labels` in output of example, got:

error: unrecognized instruction mnemonic, did you mean: cmp?
  |
  |
6 |         asm!("0: jmp 0b");
  |
note: instantiated into assembly here
note: instantiated into assembly here
 --> <inline asm>:1:5
1 |     0: jmp 0b
  |        ^



error: aborting due to 1 previous error



This error was generated by the lint-docs tool.
This tool extracts documentation for lints from the source code and places
them in the rustc book. See the declare_lint! documentation
https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint_defs/macro.declare_lint.html


To re-run these tests, run: ./x.py test --keep-stage=0 src/tools/lint-docs
The --keep-stage flag should be used if you have already built the compiler



Command DYLD_LIBRARY_PATH="/Users/runner/work/rust/rust/build/aarch64-apple-darwin/ci-llvm/lib:/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage2/lib" RUSTC="/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage0/bin/rustc" RUSTC_BOOTSTRAP="1" "/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage0-tools-bin/lint-docs" "--src" "/Users/runner/work/rust/rust/compiler" "--out" "/Users/runner/work/rust/rust/build/aarch64-apple-darwin/md-doc/rustc/src/lints" "--rustc" "/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage2/bin/rustc" "--rustc-target" "aarch64-apple-darwin" "--validate" (failure_mode=Exit, stdout_mode=Print, stderr_mode=Print) did not execute successfully.
Created at: src/core/build_steps/tool.rs:1062:23
Executed at: src/core/build_steps/doc.rs:1215:13

Build completed unsuccessfully in 0:53:40

@bors
Copy link
Contributor

bors commented Jul 19, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 19, 2024
@tgross35 tgross35 closed this Jul 19, 2024
@GuillaumeGomez GuillaumeGomez deleted the rollup-s5eqz72 branch July 19, 2024 08:55
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 A-testsuite Area: The testsuite used to check the correctness of rustc rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) 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
None yet
Development

Successfully merging this pull request may close these issues.

8 participants