Give dynamically generated instructions on how to replicate x.py errors by jyn514 · Pull Request #86022 · rust-lang/rust

jyn514 · 2021-06-05T12:56:28Z

Example output:

Checking stage0 rustdoc artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Checking rustdoc v0.0.0 (/home/joshua/rustc/src/librustdoc)
error: expected item, found `/`
--> src/librustdoc/lib.rs:1:1
|
1 | /
| ^ expected item
error: aborting due to previous error
error: could not compile `rustdoc`
To learn more, run the command again with --verbose.
command did not execute successfully: "/home/joshua/rustc/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "check" "--target" "x86_64-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "8" "--release" "--manifest-path" "/home/joshua/rustc/src/tools/rustdoc/Cargo.toml" "--message-format" "json-render-diagnostics"
expected success, got: exit status: 101
note: failed while building bootstrap::check::Rustdoc
help: to replicate this failure, run `./x.py check src/librustdoc`
failed to run: /home/joshua/rustc/build/bootstrap/debug/bootstrap check src/librustdoc
Build completed unsuccessfully in 0:00:01

Happy to take suggestions on how to improve the error message :) right
now it's getting lost in all the other output. Maybe it makes sense to
use bold and colors?

This works by storing the current step at all times in a global Mutex
and registering an at_exit handler which looks up the current step.

Fixes#84742.

rust-highfive · 2021-06-05T12:56:31Z

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

jyn514 · 2021-06-05T13:14:26Z

jyn514 · 2021-06-05T22:06:17Z

Hmm, this doesn't work very well for unit tests:

failures:
test_decode_option_none
test result: FAILED. 69 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s
error: test failed, to rerun pass '-p rustc_serialize --test json'
command did not execute successfully: "/home/joshua/rustc/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "x86_64-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "8" "--release" "--features" " llvm" "--manifest-path" "/home/joshua/rustc/compiler/rustc/Cargo.toml" "-p" "rustc_serialize" "--" "--quiet"
expected success, got: exit status: 101
note: failed while building bootstrap::test::Crate
help: to replicate this failure, run `./x.py test library/alloc`

jyn514 · 2021-06-05T22:29:14Z

Ok, should be better now:

note: failed while building bootstrap::test::Crate
help: to replicate this failure, run `./x.py test rustc_serialize --stage 0`

jyn514 · 2021-06-05T22:38:50Z

UI tests are not super helpful though:

failures:
[ui] ui/tls.rs
test result: FAILED. 0 passed; 1 failed; 1 ignored; 0 measured; 11954 filtered out; finished in 0.03s
note: failed while building bootstrap::test::Compiletest
help: to replicate this failure, run `./x.py test /home/joshua/rustc --stage 1`

jyn514 · 2021-06-05T23:11:05Z

 }
 }

+impl From<Color> for ColorChoice {


Since I'm adding termcolor anyway, it probably makes sense to remove Color and just use ColorChoice directly.

Mark-Simulacrum · 2021-06-06T01:28:02Z

FWIW I'd prefer to avoid coloring or otherwise formatting things in bootstrap. We can likely hide more of the failed command message (e.g., showing the full compile test invocation isn't necessary in non-verbose mode imo).

jyn514 · 2021-06-06T01:54:28Z

FWIW I'd prefer to avoid coloring or otherwise formatting things in bootstrap. We can likely hide more of the failed command message (e.g., showing the full compile test invocation isn't necessary in non-verbose mode imo).

Sure thing, done. I like it better with less output anyway :) It looks like this now:

Mark-Simulacrum · 2021-06-09T23:15:00Z

I am unwilling to accept the atexit and/or similar primitives to facilitate this logic. I worry that the benefit it brings seems fairly low; in practice, the full build is likely to either take a while (if, for example, the compiler has been modified, it will need to be rebuilt) or not happen -- we already should sufficiently cache that we don't rerun tests that passed without cause.

Plus, this sets precedent for us to try and fine tune the logic to allow even more precise diagnostic reporting; I'm not currently inclined to do that.

I think an alternative to this, which may be more broadly useful, is to change the formatting of the "step start" messages we currently emit such that they contain a more close reference to the necessary command to invoke that step, should any paths be available. For example, for the errors shown in this PR, we could have a log something like this, which hopefully gives a clearer indication that to rerun you can simply copy/paste the most recent step. That info: line could even be auto generated (though perhaps not auto-emitted), similar to what you've done in this PR.

info: check src/librustdoc --stage 0 --host x86_64-unknown-linux-gnu --target x86_64-unknown-linux-gnu
Checking rustdoc v0.0.0 (/home/joshua/rustc/src/librustdoc)
error: expected item, found `/`
--> src/librustdoc/lib.rs:1:1
|
1 | /
| ^ expected item
error: aborting due to previous error
error: could not compile `rustdoc`
To learn more, run the command again with --verbose.
note: failed while building bootstrap::check::Rustdoc
failed to run: /home/joshua/rustc/build/bootstrap/debug/bootstrap check src/librustdoc
Build completed unsuccessfully in 0:00:01

jyn514 · 2021-06-12T01:49:53Z

I think an alternative to this, which may be more broadly useful, is to change the formatting of the "step start" messages we currently emit such that they contain a more close reference to the necessary command to invoke that step, should any paths be available.

This is a great idea, thank you!

Plus, this sets precedent for us to try and fine tune the logic to allow even more precise diagnostic reporting; I'm not currently inclined to do that.

That info: line could even be auto generated (though perhaps not auto-emitted), similar to what you've done in this PR.

Hmm, I'm not sure I understand how these fit together? I'm fine with not using atexit, but I don't see how that will mean people don't expect it to be more precise. Maybe you meant that it will be easier to fine-tune because it's at the place the step is run (that's a convincing argument to me) but I didn't get the impression you wanted to keep the reporting precise.

jyn514 · 2021-06-12T02:19:27Z

I marked this as waiting-on-review since I'm not sure I'm on the right track - feel free to flip back to waiting-on-author if you want me to convert everything to use the new step_info() function.

Mark-Simulacrum · 2021-06-12T02:26:08Z

Just responding quickly to the last comment (haven't actually looked at code yet): changing to formatting step descriptions prior to running them in a way closely matching with their invocation is inherently high-level by virtue of steps being high level; for example, compile test invocation wouldn't/shouldn't specify a specific test in the info line, but the previous style / strategy would have been much more likely to take that tack. Doing so before the failure occurs similarly is a forcing function to print more limited information; again, this pushes the code in a less invasive direction hopefully. It also avoids dependence on primitives like atexit, which should be avoided if at all possible in my opinion.

Mark-Simulacrum · 2021-06-20T18:34:09Z

+ }
+ print!(
+ "{} {} --stage {}",
+ // TODO: this is wrong, e.g. `check --stage 1` runs build commands first


Not entirely sure how to fix this, but it seems critical to do so if we're to have some measure of success. I am hesitant to add additional annotations to the steps themselves, but perhaps that might be the way to go.

…mulacrum Make x.py less verbose on failures - Don't print the exact command run by rustbuild unless `--verbose` is set. This is almost always unhelpful, since it's just cargo with a lot of arguments (and you can't replicate it anyway unless you have the environment variables, which aren't printed by default). - Don't print "Build completed unsuccessfully" unless --verbose is set. You can already tell the build failed by the errors above, and the time isn't particularly helpful. - Don't print the full path to bootstrap. This is useless to everyone, even including when working on x.py itself. You can still opt-in to this being shown with `--verbose`, since it will throw an exception. Before: ``` error[E0432]: unresolved import `x` --> library/std/src/lib.rs:343:5 | 343 | use x; | ^ no external crate `x` error: aborting due to previous error For more information about this error, try `rustc --explain E0432`. error: could not compile `std` To learn more, run the command again with --verbose. command did not execute successfully: "/home/joshua/rustc4/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "check" "--target" "x86_64-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "8" "--release" "--features" "panic-unwind backtrace" "--manifest-path" "/home/joshua/rustc4/library/test/Cargo.toml" "--message-format" "json-render-diagnostics" expected success, got: exit status: 101 failed to run: /home/joshua/rustc4/build/bootstrap/debug/bootstrap check Build completed unsuccessfully in 0:00:13 ``` After: ``` error[E0432]: unresolved import `x` --> library/std/src/lib.rs:343:5 | 343 | use x; | ^ no external crate `x` error: aborting due to previous error For more information about this error, try `rustc --explain E0432`. error: could not compile `std` To learn more, run the command again with --verbose. ``` cc rust-lang#86854, rust-lang#86022 r? `@Mark-Simulacrum`

jyn514 · 2021-07-05T03:08:01Z

I think an alternative to this, which may be more broadly useful, is to change the formatting of the "step start" messages we currently emit such that they contain a more close reference to the necessary command to invoke that step, should any paths be available.

Hmm, so my concern with this is very easily gets lost in cargo's output:

Details

$ x check src/librustdoc
check src/librustdoc --stage 0
Compiling autocfg v1.0.0
Checking lazy_static v1.4.0
Compiling proc-macro2 v1.0.24
Compiling libc v0.2.93
Compiling unicode-xid v0.2.1
Compiling syn v1.0.65
Checking cfg-if v1.0.0
Compiling memchr v2.4.0
Checking cfg-if v0.1.10
Checking regex-syntax v0.6.22
Checking scopeguard v1.1.0
Compiling log v0.4.14
Compiling maybe-uninit v2.0.0
Compiling byteorder v1.3.4
Compiling getrandom v0.2.0
Compiling serde_derive v1.0.125
Compiling bitflags v1.2.1
Compiling ucd-trie v0.1.3
Compiling serde v1.0.125
Checking same-file v1.0.6
Compiling version_check v0.9.3
Compiling ryu v1.0.5
Checking instant v0.1.6
Checking smallvec v1.6.1
Checking fnv v1.0.7
Compiling maplit v1.0.2
Checking pin-project-lite v0.2.4
Compiling rustc-rayon-core v0.3.1
Compiling serde_json v1.0.59
Checking ppv-lite86 v0.2.8
Compiling pulldown-cmark v0.8.0
Checking ansi_term v0.12.1
Checking itoa v0.4.6
Checking either v1.6.0
Checking termcolor v1.1.2
Checking remove_dir_all v0.5.3
Checking macro-utils v0.1.3
Checking arrayvec v0.7.0
Checking thread_local v1.0.1
Checking tracing-core v0.1.17
Checking sharded-slab v0.1.1
Checking lock_api v0.4.1
Compiling crossbeam-utils v0.7.2
Compiling memoffset v0.5.5
Compiling crossbeam-epoch v0.8.2
Compiling crossbeam-utils v0.8.3
Checking walkdir v2.3.1
Compiling pest v2.1.3
Compiling unicase v2.6.0
Checking itertools v0.9.0
Checking minifier v0.0.41
Checking tracing-log v0.1.2
Checking aho-corasick v0.7.13
Checking bstr v0.2.13
Compiling quote v1.0.7
Checking regex-automata v0.1.9
Compiling pest_meta v2.1.3
Checking parking_lot_core v0.8.3
Checking num_cpus v1.13.0
Checking atty v0.2.14
Checking crossbeam-queue v0.2.3
Checking rand_core v0.6.2
Checking parking_lot v0.11.1
Checking rand_chacha v0.3.0
Checking regex v1.4.3
Checking crossbeam-deque v0.7.3
Checking rand v0.8.3
Checking matchers v0.0.1
Checking rustc-rayon v0.3.1
Checking tempfile v3.2.0
Checking globset v0.4.5
Checking ignore v0.4.17
Checking globwalk v0.8.1
Compiling pest_generator v2.1.3
Compiling tracing-attributes v0.1.13
Compiling pest_derive v2.1.0
Checking tracing v0.1.25
Checking tracing-subscriber v0.2.16
Checking tracing-tree v0.1.9
Checking rustdoc-json-types v0.1.0 (/home/joshua/rustc4/src/rustdoc-json-types)
Checking tera v1.10.0
Checking rustdoc v0.0.0 (/home/joshua/rustc4/src/librustdoc)
error[E0432]: unresolved import `x`
--> src/librustdoc/lib.rs:20:5
|
20 | use x;
| ^ no external crate `x`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0432`.
error: could not compile `rustdoc`
To learn more, run the command again with --verbose.
Build completed unsuccessfully in 0:00:18

I agree the atexit stuff is overkill, but I do think it's more useful to show at the end (showing it before seems fine to do in addition if you like). What do you think about making that part of the of destructor for Step so it runs automatically on error? And builder.ensure can explicitly cancel it if the step is successful.

jyn514 · 2021-07-14T01:31:19Z

@Mark-Simulacrum I saw you switched the labels back and forth - did you intend for them to end up as waiting-on-author? Happy to implement step() and the other implementation details in the meantime, but I'd like to hear a response to #86022 (comment) before merging.

…ring the build progress

- add stage override - switch more things to step_info

jyn514 · 2021-07-24T19:46:25Z

I think an alternative to this, which may be more broadly useful, is to change the formatting of the "step start" messages we currently emit such that they contain a more close reference to the necessary command to invoke that step, should any paths be available.

I implemented this. I'm feeling a little burned out on this PR, I'd like to land what I have so far if at all possible.

rust-log-analyzer · 2021-07-24T20:15:44Z

The job x86_64-gnu-llvm-10 failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)

 Compiling ansi_term v0.11.0
Compiling difference v2.0.0
Compiling pretty_assertions v0.6.1
Compiling bootstrap v0.0.0 (/checkout/src/bootstrap)
error[E0445]: crate-private trait `builder::Step` in public interface
--> src/bootstrap/cache.rs:274:5
|
274 | pub fn all<S: Ord + Step>(&mut self) -> Vec<(S, S::Output)> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't leak crate-private trait
::: src/bootstrap/builder.rs:54:1
|
|
54 | pub(crate) trait Step: 'static + Clone + Debug + PartialEq + Eq + Hash {
| ---------------------------------------------------------------------- `builder::Step` declared as crate-private
error[E0445]: crate-private trait `builder::Step` in public interface
--> src/bootstrap/cache.rs:286:5
|
286 | pub fn contains<S: Step>(&self) -> bool {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't leak crate-private trait
::: src/bootstrap/builder.rs:54:1
|
|
54 | pub(crate) trait Step: 'static + Clone + Debug + PartialEq + Eq + Hash {
| ---------------------------------------------------------------------- `builder::Step` declared as crate-private
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0445`.
error: could not compile `bootstrap`

bors · 2021-07-27T16:29:17Z

☔ The latest upstream changes (presumably #87509) made this pull request unmergeable. Please resolve the merge conflicts.

JohnCSimon · 2021-09-20T00:39:43Z

Ping from triage:
@jyn514 Merge conflicts

jyn514 added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) A-contributor-roadblock Area: Makes things more difficult for new or seasoned contributors to Rust labels Jun 5, 2021

rust-highfive assigned Mark-Simulacrum Jun 5, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 5, 2021

This comment has been minimized.
Sign in to view

jyn514 force-pushed the better-errors branch from 5ed39fe to 9fd68c9Compare June 5, 2021 13:13

This comment has been minimized.
Sign in to view

jyn514 commented Jun 5, 2021
View reviewed changes

jyn514 mentioned this pull request Jun 6, 2021
impl {Default, FromStr} for ColorChoiceBurntSushi/termcolor#42
Closed

This comment has been minimized.
Sign in to view

jyn514 force-pushed the better-errors branch from 5c54890 to 2c80938Compare June 6, 2021 02:05

jyn514 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 11, 2021

jyn514 added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 12, 2021

This comment has been minimized.
Sign in to view

Mark-Simulacrum reviewed Jun 20, 2021
View reviewed changes

Mark-Simulacrum added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 20, 2021

jyn514 added 7 commits July 24, 2021 19:07

Give dynamically generated instructions on how to replicate errors du…
32fd96c
…ring the build progress

more progress
35b1673
- add stage override - switch more things to step_info

Use compiler() instead of stage()
95d4071

rewrite some more code
c55e2bd

Add StepInfo
e24f28a

Change some things to use step_info
a6f8a1d

cleanup
c47f73b

jyn514 force-pushed the better-errors branch from 8aa0c87 to c47f73bCompare July 24, 2021 19:45

crlf0710 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 14, 2021

camelid added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 2, 2021

jyn514 closed this Sep 20, 2021

jyn514 deleted the better-errors branch September 20, 2021 01:40

jyn514 mentioned this pull request Mar 3, 2022
Hide failed command unless in verbose mode #93492
Merged

jyn514 mentioned this pull request May 24, 2022
Give dynamically generated instructions on how to replicate x.py errors #97338
Open

jyn514 mentioned this pull request Sep 19, 2022
Make the status messages emitted by bootstrap more clear #102003
Closed

jyn514 restored the better-errors branch November 5, 2022 20:30

jyn514 mentioned this pull request Feb 17, 2023
Improve building compiler artifacts output #108171
Merged

Uh oh!

Uh oh!

Conversation

jyn514 commented Jun 5, 2021

Uh oh!

rust-highfive commented Jun 5, 2021

Uh oh!

This comment has been minimized.

jyn514 commented Jun 5, 2021

Uh oh!

jyn514 commented Jun 5, 2021

Uh oh!

jyn514 commented Jun 5, 2021

Uh oh!

jyn514 commented Jun 5, 2021

Uh oh!

This comment has been minimized.

jyn514Jun 5, 2021

Choose a reason for hiding this comment

Uh oh!

Mark-Simulacrum commented Jun 6, 2021

Uh oh!

jyn514 commented Jun 6, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

Mark-Simulacrum commented Jun 9, 2021

Uh oh!

jyn514 commented Jun 12, 2021

Uh oh!

jyn514 commented Jun 12, 2021

Uh oh!

Mark-Simulacrum commented Jun 12, 2021

Uh oh!

This comment has been minimized.

Mark-SimulacrumJun 20, 2021

Choose a reason for hiding this comment

Uh oh!

jyn514 commented Jul 5, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jyn514 commented Jul 14, 2021

Uh oh!

jyn514 commented Jul 24, 2021

Uh oh!

rust-log-analyzer commented Jul 24, 2021

Uh oh!

bors commented Jul 27, 2021

Uh oh!

JohnCSimon commented Sep 20, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

jyn514 commented Jun 6, 2021•
edited
Loading

jyn514 commented Jul 5, 2021•
edited
Loading