Debugging support in rustc

[amanjeev]

This is still work-in-progress but I wanted to open a PR for an early review to see if I am on the right path (also suggested by @spastorino).
This document is built on top of https://www.youtube.com/watch?v=elBxMRSNYr4 by @tromey.

For the sake of simplicity, I have added this document at the top level. Please advise if this should be under a directory or group of docs.

• Add explanation to note that this document is about debugging Rust code rather than debugging the compiler itself.
• Add first questions inline to the code on this PR for missing details and my confusions.
• CHECK What is SIP and link to it.
• Add the description of what is debugger etc. in preliminary section.
• Create Youtube's subtitles using this comment. (I personally find the auto-generated text to be horrible)
• Add TODOs for pending answers and iterate (as discussed with @mark-i-m and folks in WG-Learning meeting on 2019-06-11)

This issue has been assigned to @amanjeev via this comment.

[igaray]

I would add this as a subsection under the Debugging the Compiler chapter in Part 1.

[amanjeev]

I would add this as a subsection under the Debugging the Compiler chapter in Part 1.

Now that I look at this, I wonder if it is ok as a subsection, given this is pretty long.

[igaray]

I mean, still in it's own file as it currently is, just indexed under the debugging chapter.

[amanjeev]

Not sure what cannot be done but this was mentioned by @tromey in the video. Perhaps he did explain later which I have noted in this document below, but I still am not sure if there is something more to this.

[tromey]

gdb's Rust extensions and limitations are documented in the gdb manual: https://sourceware.org/gdb/onlinedocs/gdb/Rust.html -- however, this neglects to mention that gdb convenience variables and registers follow the gdb $ convention, and that the Rust parser implements the gdb @ extension.

[amanjeev]

however, this neglects to mention that gdb convenience variables and registers follow the gdb $ convention, and that the Rust parser implements the gdb @ extension.

@tromey do you think we should mention this part in the GDB-Rust document rather than this document so there is no duplication etc.?

[amanjeev]

@tromey could you please help me find where this demangler is at the moment? Or do we even have one? Checking because you say @michaelwoerister (I think) says that we should change Rust's name mangling.

[amanjeev]

Very amateur question - What's the best way to turn off linkchecker while working with a document? It takes forever to reload the page with the changes locally.

[mark-i-m]

@amanjeev The easiest way is just to change this to false:

https://github.com/rust-lang/rustc-guide/blob/14b243de252da65e26dc3f60676d288f8c2af8b6/book.toml#L11

[mark-i-m]

@amanjeev Thanks :) I will try to get to this soon. It looks like there have already been some comments, so I will try to make it a quick review

[mark-i-m]

Also, you have a merge conflict

[amanjeev]

@mark-i-m Sorry, I will try and resolve the conflicts and push again. I used to think I was good at this. lol

[amanjeev]

Not sure what's going on here. I see this build error but the pages exist. Do we need to increase the timeout maybe? Please help.

appendix/code-index.md#11: There was an error while fetching "https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Crate.html", https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Crate.html: timed out```

[mark-i-m]

Yes, I’ve been seeing a lot of those timeouts recently. I think it is travis rate limiting us. It seems to be a different link every time. @pietroalbini any ideas?

[amanjeev]

Seems I cannot re-run Travis builds without a commit? What are some of the other options to do that?

[mark-i-m]

I can rerun travis builds, but I tried that on a previous PR and it doesn't solve the problem (there will be a timeout on another link). I would like to hear if the infra team has any ideas here.

[emilyalbini]

Yes, I’ve been seeing a lot of those timeouts recently. I think it is travis rate limiting us. It seems to be a different link every time. @pietroalbini any ideas?

Those are spurious network issues, we also see them on rustc when talking with AWS (like S3 or a CloudFront-backed domain like doc.rust-lang.org). They're aware of it as far as I can tell, but there doesn't seem to be that much progress.

[amanjeev]

So meanwhile someone will be sitting at their desk clicking the "Re-run build" button. I do not envy you @mark-i-m 😄

[amanjeev]

@mark-i-m it passed! 😅

[amanjeev]

@rustbot claim

[mark-i-m]

@amanjeev Thanks for your patience and your hard work. Overall LGTM. I left a bunch of small nits. After those are fixed, r=me :)

[mark-i-m]

Also watch out because github likes to "Helpfully" collapse comments...

[amanjeev]

@mark-i-m I am unaware of what r=me means but this is all yours now, I think. Please check.

[mark-i-m]

@amanjeev It looks good to me! Let's ship it

I am unaware of what r=me means...

In the rust-lang/rust repo, where bors controls the PR queue, reviewers leave comments like @bors r+ or @bors r=mark-i-m to indicate that they approve the PR and it should be merged by bors. Thus it became a convention that r=me means "I will approve this" usually with some small request attached (e.g. rust-lang/rust#61626 (review)).

[mark-i-m]

@amanjeev I tried to rebase and resolve the conflicts, but somewhere along the way there were a few very weird merge conflicts, so I just squashed all commits and rebased on the current master. When travis turns green, I will merge.

[amanjeev]

@mark-i-m thank you so much! I am so happy this is merged! 🎉