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

Add a dedicated debug-logging option to config.toml #76588

Merged
merged 3 commits into from
Sep 13, 2020

Conversation

guswynn
Copy link
Contributor

@guswynn guswynn commented Sep 10, 2020

@Mark-Simulacrum and I were talking in zulip and we found that turning on debug/trace logging in rustc is fairly confusing, as it effectively depends on debug-assertions and is not documented as such. @Mark-Simulacrum mentioned that we should probably have a separate option for logging anyways.

this diff adds that, having the option follow debug-assertions (so everyone's existing config.toml should be fine) and if the option is false

to test I ran ./x.py test twice, once with debug-logging = false and once with debug-logging = true and made sure i only saw trace's when it was true

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 10, 2020
# Whether or not to leave debug! and trace! calls in the rust binary.
# Overrides the `debug-assertions` option, if defined.
#
# Defaults to rust.debug-assertions value
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, so this brings up two interesting questions:

  • Should we default to this being on? If you're doing a lot of rustc development, it can certainly be helpful to have debug logs, but it can also be a pretty annoying slowdown (IIRC, benchmarks show 5-10%).
  • Show we tie to to the old way of turning it on, i.e., debug-assertions?

cc @jyn514, we might want an MCP or similar here to figure out what people think good defaults would be.

Copy link
Member

@jyn514 jyn514 Sep 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should start as off-by-default. There was a lot of discussion in #76588 about enabling logging and it was almost a 10% perf hit on some benchmarks: https://perf.rust-lang.org/compare.html?start=22e6099330cde0e7b1529774fe27874f8326de7a&end=ededceef5651050bda1a2058af270da498bb1333.

That said, I would love to get the perf impact low enough that this can be on by default (or even always on).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That said, I would love to get the perf impact low enough that this can be on by default (or even always on).

One possible way to do this is to separate debug! from trace! and have that be opt-in instead. AFAIK most of the compiler uses debug! currently, but I separate the two in rustdoc and it's worked very well. In particular, collect_intra_doc_links prints ludicrous amounts of info with trace but only ~15 lines or so per module with debug: https://github.com/rust-lang/rust/blob/master/src/librustdoc/passes/collect_intra_doc_links.rs#L647

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As it is implemented now, it should be off by default, and on wit debug-assertions, which matched exactly the semantics of the current config.toml

Copy link
Member

@Mark-Simulacrum Mark-Simulacrum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation looks great here, left a few questions/concerns.

src/bootstrap/lib.rs Outdated Show resolved Hide resolved
@Mark-Simulacrum
Copy link
Member

I'm going to re-assign to @jyn514 who can hopefully drive the defaults discussion here, but r=me from a pure implementation perspective (with the comment nit fixed).

@guswynn guswynn force-pushed the debug_logging branch 2 times, most recently from d33347d to 114473f Compare September 10, 2020 22:58
@jyn514 jyn514 added the T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) label Sep 11, 2020
Copy link
Member

@jyn514 jyn514 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

r=me with documentation updated, I think any changes to the defaults should be separate from the implementation. Having this default to debug-assertions is a good idea though IMO :)

config.toml.example Outdated Show resolved Hide resolved
@jyn514 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 Sep 11, 2020
@jyn514
Copy link
Member

jyn514 commented Sep 11, 2020

@bors r=jyn514,Mark-Simulacrum

Thanks for working on this! I'll open a separate issue for turning on debug logging by default (#76588 (comment)), but that's a long-term project and shouldn't block this improvement.

@bors
Copy link
Contributor

bors commented Sep 11, 2020

📌 Commit 0be66d7 has been approved by jyn514,Mark-Simulacrum

@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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 11, 2020
@guswynn
Copy link
Contributor Author

guswynn commented Sep 11, 2020

@jyn514 I might see if I have time for some work on #76588 (comment)

Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Sep 12, 2020
…k-Simulacrum

Add a dedicated debug-logging option to config.toml

@Mark-Simulacrum and I were talking in zulip and we found that turning on debug/trace logging in rustc is fairly confusing, as it effectively depends on debug-assertions and is not documented as such. @Mark-Simulacrum mentioned that we should probably have a separate option for logging anyways.

this diff adds that, having the option follow debug-assertions (so everyone's existing config.toml should be fine) and if the option is false

to test I ran ./x.py test <something> twice, once with `debug-logging = false` and once with `debug-logging = true` and made sure i only saw trace's when it was true
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Sep 12, 2020
…k-Simulacrum

Add a dedicated debug-logging option to config.toml

@Mark-Simulacrum and I were talking in zulip and we found that turning on debug/trace logging in rustc is fairly confusing, as it effectively depends on debug-assertions and is not documented as such. @Mark-Simulacrum mentioned that we should probably have a separate option for logging anyways.

this diff adds that, having the option follow debug-assertions (so everyone's existing config.toml should be fine) and if the option is false

to test I ran ./x.py test <something> twice, once with `debug-logging = false` and once with `debug-logging = true` and made sure i only saw trace's when it was true
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Sep 12, 2020
…k-Simulacrum

Add a dedicated debug-logging option to config.toml

@Mark-Simulacrum and I were talking in zulip and we found that turning on debug/trace logging in rustc is fairly confusing, as it effectively depends on debug-assertions and is not documented as such. @Mark-Simulacrum mentioned that we should probably have a separate option for logging anyways.

this diff adds that, having the option follow debug-assertions (so everyone's existing config.toml should be fine) and if the option is false

to test I ran ./x.py test <something> twice, once with `debug-logging = false` and once with `debug-logging = true` and made sure i only saw trace's when it was true
@bors
Copy link
Contributor

bors commented Sep 13, 2020

⌛ Testing commit 0be66d7 with merge 4e48010...

@rust-log-analyzer
Copy link
Collaborator

Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @rust-lang/infra. (Feature Requests)

@bors
Copy link
Contributor

bors commented Sep 13, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: jyn514,Mark-Simulacrum
Pushing 4e48010 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 13, 2020
@bors bors merged commit 4e48010 into rust-lang:master Sep 13, 2020
@rustbot rustbot added this to the 1.48.0 milestone Sep 13, 2020
@guswynn guswynn deleted the debug_logging branch September 15, 2020 15:27
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Oct 10, 2020
Clarify the debug-related values should take boolean

rust-lang#76588 tweaked their placeholders but these values should take boolean and the current placeholders are confusing, at least for me.
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Oct 10, 2020
Clarify the debug-related values should take boolean

rust-lang#76588 tweaked their placeholders but these values should take boolean and the current placeholders are confusing, at least for me.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants