Merge pull request #254 from chrissimpkins/rustc-dev-guide-rename

Transition rustc-guide to rustc-dev-guide

Author: spastorino

content/_index.md

@@ -7,16 +7,16 @@ type: docs
 A home for compiler team planning documents, meeting minutes, and
 other such things. If you're interested in learning about how
 **rustc** works -- as well as advice on building the compiler, preparing a PR,
-and other similar topics -- check out the [rustc-guide].
+and other similar topics -- check out the [rustc-dev-guide].
 
-[rustc-guide]: https://rust-lang.github.io/rustc-guide/
+[rustc-dev-guide]: https://rustc-dev-guide.rust-lang.org/
 
 ## Quick facts
 
 - **Where to find us:** We are primarily present on [Zulip](about/chat-platform), though some of us also monitor Discord.
 - **Want to attend a meeting or follow along?** See the "meeting calendar" section below.
 - **Looking for technical information about how the compiler works?**
-  Check out the [rustc-guide](https://rust-lang-nursery.github.io/rustc-guide/).
+  Check out the [rustc-dev-guide](https://rustc-dev-guide.rust-lang.org/).
 
 ## Meeting Calendar
 
@@ -73,7 +73,7 @@ Name                                                      | Status       | Short
 [MIR Optimizations](working-groups/mir-opt/)              | Active       | Write MIR optimizations and refactor the MIR to be more optimizable.                               | [#t-compiler/wg-mir-opt][mir-opt-stream]
 [Rustc pipelining](working-groups/pipelining/)            | Active       | Enable Cargo to invoke rustc in a pipelined fashion, speeding up crate graph compiles.             | [#t-compiler/wg-pipelining][pipelining-stream]
 [Polonius](working-groups/polonius/)                      | Active       | Exploring the integration of the "NLL 2.0"-like ["Polonius analysis"][Polonius] into rustc         | [#t-compiler/wg-polonius][polonius_stream]
-[Learning](working-groups/learning/)                      | Active       | Make the compiler easier to learn by ensuring that rustc-guide and api docs are "complete"         | [#t-compiler/wg-learning][learning_stream]
+[Learning](working-groups/learning/)                      | Active       | Make the compiler easier to learn by ensuring that rustc-dev-guide and api docs are "complete"         | [#t-compiler/wg-learning][learning_stream]
 [Diagnostics](working-groups/diagnostics/)                | Active       | Use crates.io crates for diagnostics rendering and make emitting diagnostics nicer.                | [#t-compiler/wg-diagnostics][diagnostics_stream]
 [Polymorphization](working-groups/polymorphization/)      | Active       | Implement an analysis to detect when functions can remain polymorphic during code generation.      | [#t-compiler/wg-polymorphization][polymorphization_stream]
 [Profile-Guided Optimization](working-groups/pgo/)        | Retired      | Implementing profile-guided optimization for rustc                                                 | [#t-compiler/wg-profile-guided-optimization][pgo_stream]

content/minutes/design-meeting/2019-07-08-triage-wg.md

@@ -106,7 +106,7 @@ assigned to do a preliminary review or fix. We need to improve the
 "expert map" to be more complex and also to include "levels of
 knowledge". Perhaps rename it to "knowledge map" or something like
 that. Also, this can be a great way to figure out things that need to
-be added to the rustc-guide.
+be added to the rustc-dev-guide.
 
 [expert map]: https://github.com/rust-lang/compiler-team/blob/master/experts/MAP.md
 

content/minutes/design-meeting/2019-10-11-DepGraph-persistence-PR62038.md

@@ -13,7 +13,7 @@ Dear @*T-compiler/meeting*,
 
 Today we will be having a **design meeting**. The topic was originally sketched as "some Zoxc PR". We've since narrowed that down to discuss #62038, which is a refactoring to how dep-graph loading occurs. @**Zoxc** [wrote up a comment](https://github.com/rust-lang/rust/pull/62038#issuecomment-540508308) giving a summary of the ideas. Note that this PR itself is an incremental step towards #60035, which aims to make dep-graph loading/saving more continuous.
 
-I'd also like to discuss briefly how we should document these changes. We currently have some rustc-chapters on incremental compilation (e.g., [this chapter goes into detail](https://rust-lang.github.io/rustc-guide/queries/incremental-compilation-in-detail.html)). I would like to move us to a world where major refactorings like #60035 (but not limited to this one -- I think e.g. [my recent PR](https://github.com/rust-lang/rust/pull/65232) and work on lazy norm fits the bill) come along with a rustc-guide chapter that documents the new state of the world. Maybe we discuss some how that might work and -- in the case of THIS PR -- who might do that documentation work (I don't necessarily think it has to be @**Zoxc**, though they're also an obvious candidate). (In my ideal world, drafts of that chapter would be available *before* the PR, but at minimum I think such a chapter should be in place to help with reviewing.)
+I'd also like to discuss briefly how we should document these changes. We currently have some rustc-chapters on incremental compilation (e.g., [this chapter goes into detail](https://rustc-dev-guide.rust-lang.org/queries/incremental-compilation-in-detail.html)). I would like to move us to a world where major refactorings like #60035 (but not limited to this one -- I think e.g. [my recent PR](https://github.com/rust-lang/rust/pull/65232) and work on lazy norm fits the bill) come along with a rustc-dev-guide chapter that documents the new state of the world. Maybe we discuss some how that might work and -- in the case of THIS PR -- who might do that documentation work (I don't necessarily think it has to be @**Zoxc**, though they're also an obvious candidate). (In my ideal world, drafts of that chapter would be available *before* the PR, but at minimum I think such a chapter should be in place to help with reviewing.)
 
 ## Questions for discussion
 
@@ -54,5 +54,5 @@ I'd also like to discuss briefly how we should document these changes. We curren
     * Conclusion:
         * Follow-up meeting to dig into design of #60035 and maybe discuss alternatives
         * In parallel, Niko will review #62038 now that he understands roughly what it is trying to do
-            * We would also want to write docs for rustc-guide
+            * We would also want to write docs for rustc-dev-guide
             * We can figure out how that happens in parallel

content/minutes/design-meeting/2019-12-20-major-change-process.md

@@ -120,8 +120,8 @@ We would know the system is working if:
     * the only "hard block" would be if you don't have a "partner" or "sponsor" from compiler team
     * somewhat analogous to the project group lang team concepts
 * reviewer not expected to be a pair programmer
-* one possible definition for "what is a major change" might be "what would modify the rustc-guide"
-    * or, since rustc-guide is always a WIP, "welp this *should've* in the guide and if it were, it *would've* required a modification"
+* one possible definition for "what is a major change" might be "what would modify the rustc-dev-guide"
+    * or, since rustc-dev-guide is always a WIP, "welp this *should've* in the guide and if it were, it *would've* required a modification"
 * what to do with new PRs that don't follow the process?
     * should we close them?
     * maybe have a canned comment and give them some amount of time
@@ -143,16 +143,16 @@ We would know the system is working if:
         * would like to review performance results
         * we need a `-Z` flag
         * we need docs :)
-* final discussion point was about exactly how to handle requests for rustc-guide edits
-    * since a major change is part of a rustc-guide change, it makes sense that it should come accompanied with a rustc-guide write-up
+* final discussion point was about exactly how to handle requests for rustc-dev-guide edits
+    * since a major change is part of a rustc-dev-guide change, it makes sense that it should come accompanied with a rustc-dev-guide write-up
     * ideally this would come along with the compiler-team issue
         * but maybe it would be more something we wait for until issue is *approved* or, in extreme cases, co-develop with author
     * if we want to see more docs, we are going to have to start holding the line *somewhere*
     * sometimes it's not possible or desirable to write complete docs before-hand
         * details may change through review process
         * person may not know enough context to write the docs, need help with that
     * but the bar should be that the issue can **explain the change** in sufficient detail for it to be understood
-        * the *actual* rustc-guide changes themselves can come later
+        * the *actual* rustc-dev-guide changes themselves can come later
         * it may be that the role of the learning wg can be to help with some of that
 
 ## Final proposed process
@@ -162,8 +162,8 @@ We would know the system is working if:
     * Identify mentors or reviewers, if you are working with one
     * There will be some "prototype" to guide people in this
 * What is a "major change"?
-    * something where it would make sense to update rustc-guide
-    * if rustc-guide doesn't cover this code yet, then you may have to use your imagination about what *ought* to be documented :)
+    * something where it would make sense to update rustc-dev-guide
+    * if rustc-dev-guide doesn't cover this code yet, then you may have to use your imagination about what *ought* to be documented :)
 * These issues will be reviewed by compiler team members
     * Compiler team members and contributors can leave concerns and approvals asynchronously (see below)
         * maybe we can make a dedicated Zulip stream where new things get 

content/minutes/steering-meeting/2018-10-26.md

@@ -31,4 +31,4 @@ We pointed out that when we do our planning at [the next Rust All Hands](https:/
 
 We discussed some how the [diagnostics efforts could be increased](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136551512).
 
-We discussed [the rustc-guide](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136552030) as well as the [NLL contributor YouTube videos](https://www.youtube.com/playlist?list=PLCQVvhKUrTN9VfaQx2AyOSAstwENaGkYA) and ways to improve them. One solid thought was that we might want to create a rustc-guide WG ([which has its own zulip topic here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rustc-guide-wg)). We talked in particular about how both [experienced folks and newcomers can contribute there](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136552969).
+We discussed [the rustc-dev-guide](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136552030) as well as the [NLL contributor YouTube videos](https://www.youtube.com/playlist?list=PLCQVvhKUrTN9VfaQx2AyOSAstwENaGkYA) and ways to improve them. One solid thought was that we might want to create a rustc-dev-guide WG ([which has its own zulip topic here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rustc-guide-wg)). We talked in particular about how both [experienced folks and newcomers can contribute there](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-10-26/near/136552969).

content/minutes/steering-meeting/2018-12-14.md

@@ -35,7 +35,7 @@ experienced](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/su
   - writing tests can be driven via [code coverage measurements](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151782245)
   - writing docs can be driven via
     [`deny(missing_docs)`](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151781803)
-    as well as [push to complete the missing rustc-guide
+    as well as [push to complete the missing rustc-dev-guide
     sections](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151781969)
   - one problem with writing documentation is that [there always seems
     to be something that is higher
@@ -55,11 +55,11 @@ is documented.
 
 - [before landing a massive refactoring or new architecture](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151784501):
   - ideally, [talk out the design on an internals thread to achieve some light consensus](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151784204)
-  - expect documentation [in the form of rustc-guide chapters](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151783865)
+  - expect documentation [in the form of rustc-dev-guide chapters](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151783865)
 - some examples where we should do this:
   - [end-to-end queries](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151783972)
   - [parallel query execution](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151784316)
-- in terms of the rustc-guide:
+- in terms of the rustc-dev-guide:
   - it'd be [great to improve mdbook to permit for graphs](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151783887)
     - maybe we can [add graphviz support into mdbook](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151784431)
   - we should [not neglect doc comments](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/steering.20meeting.202018-12-14/near/151784445)

content/minutes/steering-meeting/2019-01-04.md

@@ -37,7 +37,7 @@ e.g., rustdoc or RLS.
 
 We discussed some possibler areas for discussion:
 
-- [the rustc-guide](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154415509)
+- [the rustc-dev-guide](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154415509)
 - [related work, like RLS, rustdoc,](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154415505)
   or [cranelift](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154415743)
 - [mentoring?](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019-01-04/near/154415632)

content/minutes/steering-meeting/2019-03-01.md

@@ -92,10 +92,10 @@ responsible for any repository we create in the rust-lang organization.
 valuable and should point to the responsible working group.
 
 Changing gears, [@mw][mw] asked if there were any example workflows for handling changes in external
-crates to which [@nikomatsakis][nikomatsakis] suggested that a rustc-guide chapter on that and
+crates to which [@nikomatsakis][nikomatsakis] suggested that a rustc-dev-guide chapter on that and
 how to make local copies for debugging would be necessary. [@davidtwco][davidtwco] asked what
 information should be kept in the policy document and what information should be kept in the
-rustc-guide. There was some consensus that setting up a new out-of-tree crate is policy and working
+rustc-dev-guide. There was some consensus that setting up a new out-of-tree crate is policy and working
 with one is for the guide.
 
 [@mw][mw] then raised the question of where consent of compiler team members should be gathered

content/minutes/steering-meeting/2019-04-12.md

@@ -99,7 +99,7 @@ wind up detailed enough that [frequent contributors can pick them up
 and implement
 them](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163195172),
 even if the people *making* the design are busy with other things.
-Similarly, [design documents can become the basis for rustc-guide
+Similarly, [design documents can become the basis for rustc-dev-guide
 chapters](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/steering.20meeting.202019.2E04.2E12.20.2358850/near/163195352).
 
 [We plan to flesh out some more details and put this idea into action

content/minutes/triage-meeting/2019-08-15.md

@@ -18,12 +18,12 @@ type: docs
 
 ### [wg-learning](https://rust-lang.github.io/compiler-team/working-groups/learning/)
 
-wg-learning's objective is to make the compiler easier to learn by ensuring that rustc-guide and api docs are "complete".
+wg-learning's objective is to make the compiler easier to learn by ensuring that rustc-dev-guide and api docs are "complete".
 
 Currently they're working on:
 
 1. Getting [video lectures](https://www.youtube.com/watch?v=mAUGvNgZYtw) about parts of the compiler from people who know them
-2. Turning existing video lectures into content for the [rustc-guide](https://github.com/rust-lang/rustc-guide)
+2. Turning existing video lectures into content for the [rustc-dev-guide](https://github.com/rust-lang/rustc-dev-guide)
 3. Triaging and working on issues and pull requests for learning content
 
 Help is always wanted!