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.

Sign up for GitHub

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

Jump to bottom

Is it possible to get cargo's output as json? #1403

Closed
sbstp opened this issue Mar 10, 2015 · 11 comments
Closed

Is it possible to get cargo's output as json? #1403

sbstp opened this issue Mar 10, 2015 · 11 comments
Labels
A-tooling Area: interaction with other tools

Comments

@sbstp
Copy link

sbstp commented Mar 10, 2015

I'd like to integrate cargo into Atom (the text editor) and I was wondering if it is possible to get the commands' result as json. I'd like to be able to get errors and their line number from cargo build as well as test results from cargo test.
@alexcrichton
Copy link
Member

Unfortunately no, this aspect of Cargo has not yet been implemented. Cargo is planned to have more tooling support with nice machine-readable output formats (like JSON or TOML). For test results, however, that would be a problem more of the testing framework than Cargo itself, so it may not necessarily be up to Cargo to do so.

@alexcrichton alexcrichton added the A-tooling Area: interaction with other tools label Mar 10, 2015
@sbstp
Copy link
Author

sbstp commented Mar 10, 2015

What is the testing framework that cargo runs when you use cargo test?

@alexcrichton
Copy link
Member

Currently it's libtest in the standard distribution.

@steveklabnik
Copy link
Member

And we removed it fairly recently in an effort to streamline the runner, since we didn't want to stabilize it.

@oli-obk
Copy link
Contributor

oli-obk commented Mar 4, 2016

since rustc can now output json, at least cargo build could get a setting to output json

@bruno-medeiros bruno-medeiros mentioned this issue Mar 22, 2016
Closed
@matklad
Copy link
Member

matklad commented May 9, 2016 •
edited
Loading

Can RUSTFLAGS env variable be used here?

@Boddlnagg
Copy link
Contributor

No, it can't: rust-lang/rust#37011

@alexcrichton
Copy link
Member

With --message-format=json now stable, I'm going to close this.

@aergonaut
Copy link

Sorry to necropost, but I figured this issue was a good place to bring up this point than creating a new one.

Are there plans to add JSON output for cargo test results? While I see there's --message-format=json it looks like that only makes the build step output JSON, and the actual test results are still in the human-readable pretty format.

My motivation is that I want to build a Nuclide test runner provider for Atom, and it would be a lot easier to parse test results if they were output in JSON.

@alexcrichton
Copy link
Member

@aergonaut ah the test framework (src/libtest/lib.rs in the rust-lang/rust repository) is actually somewhat separate from the current implementation of --message-format=json). It's definitely desired to have a more full-featured testing framework in the long run, though! We've long wanted the ability to have custom test frameworks to implement this logic.

@aergonaut
Copy link

Thanks for the reply @alexcrichton. I'll look forward to hopefully seeing that RFC make progress in the future 😃

@okhin okhin mentioned this issue Sep 10, 2018
Closed
github-merge-queue bot pushed a commit that referenced this issue Feb 28, 2025
@epage
Bump cc to 1.2.16 to fix x86 windows jobs in rust-lang/rust CI (#…
2622e84 
…15245)

### What does this PR try to resolve?

GitHub Runner Images 20250224.5.0+ ship Windows 11 SDK 10.0.26100+
compared to the previous Windows 11 SDK 10.0.22621, which bumped the
UCRT headers. The new UCRT headers use SSE2 types. However, `cc`
versions <= 1.2.15 emit `/arch:IA32` for `x86` Windows targets for
`clang-cl`, which causes compilation errors since `clang-cl` can't find
SSE2 types without `/arch:SSE2` specified (or defaulted). (Note that
MSVC at the time of writing silently accepts and emits instruments for
code using SSE2 types, as opposed to `clang-cl` hard error-ing).

`cc` 1.2.16 contains a fix for this problem,
rust-lang/cc-rs#1425, to correctly emit
`/arch:SSE2` instead of `/arch:IA32` to enable `clang-cl` to find the
SSE2 types. However, cargo's `cc` currently is still on 1.2.13.

To fix this for rust-lang/rust CI, we need to bump anything that
transitively relies on `cc` and tries to use `clang-cl` on `x86` Windows
targets to compile any C/C++ code that transitively use functions or
types that require SSE2 types, such as `<wchar.h>`.

### How should we test and review this PR?

The fix was initially intended for `rustc_{codegen_ssa,llvm}` `cc`, and
based on testing in rust-lang/rust#137724, I was
able to successfully build `rustc_{codegen_ssa,llvm}` with a forked `cc`
based on 1.2.15 which contains the fix from
rust-lang/cc-rs#1425. Note that in the same PR,
while the compiler build succeeded, the build of cargo itself failed
since it transitively used a `cc` *without* the fix to build
`curl-sys`[^dep-chain], which failed as one might expect (`curl-sys`
tries to build C code that uses `<wchar.h>` which runs into the same
problem). Hence, this PR is opened to bump cargo's `cc` to a `cc`
version containing the fix.

### Additional information

This `x86` Windows CI problem is:

- Discussed in
https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/spurious.20.28.3F.29.20i686.20msvc.20errors.
- Tracked by rust-lang/rust#137733.

#### `cc` changelog between 1.2.13 and 1.2.16

<details>
<summary>`cc` changes since 1.2.13 up to and including 1.2.16</summary>

#####
[1.2.16](rust-lang/cc-rs@cc-v1.2.15...cc-v1.2.16)
- 2025-02-28

###### Fixed

- force windows compiler to run in `out_dir` to prevent artifacts in cwd
(#1415)

###### Other

- use `/arch:SSE2` for `x86` target arch (#1425)
- Regenerate windows-sys binding
([#1422](rust-lang/cc-rs#1422))
- Regenerate target info
([#1418](rust-lang/cc-rs#1418))
- Add LIB var when compiling flag_check (#1417)
- Change flag ordering
([#1403](rust-lang/cc-rs#1403))
- Fix archiver detection for musl cross compilation
([#1404](rust-lang/cc-rs#1404))

#####
[1.2.15](rust-lang/cc-rs@cc-v1.2.14...cc-v1.2.15)
- 2025-02-21

###### Other

- Regenerate target info
([#1406](rust-lang/cc-rs#1406))
- Always read from all `CFLAGS`-style flags
([#1401](rust-lang/cc-rs#1401))
- Simplify the error output on failed `Command` invocation
([#1397](rust-lang/cc-rs#1397))

#####
[1.2.14](rust-lang/cc-rs@cc-v1.2.13...cc-v1.2.14)
- 2025-02-14

###### Other

- Regenerate target info
([#1398](rust-lang/cc-rs#1398))
- Add support for setting `-gdwarf-{version}` based on RUSTFLAGS
([#1395](rust-lang/cc-rs#1395))
- Add support for alternative network stack io-sock on QNX 7.1 aarch64
and x86_64 ([#1312](rust-lang/cc-rs#1312))

</details>

[^dep-chain]: I think the dep chain is something like git2 ->
libgit2-sys -> curl -> curl-sys?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-tooling Area: interaction with other tools
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@steveklabnik @alexcrichton @aergonaut @oli-obk @sbstp @Boddlnagg @matklad