From 595f2f386c67d0ef3719c6b71c84de2069662c8c Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 31 Mar 2020 15:30:27 -0500 Subject: [PATCH] and a few more links --- src/appendix/stupid-stats.md | 6 +++--- src/compiler-team.md | 5 ++--- src/tests/intro.md | 2 +- 3 files changed, 6 insertions(+), 7 deletions(-) diff --git a/src/appendix/stupid-stats.md b/src/appendix/stupid-stats.md index 7453f4424..a07956f0f 100644 --- a/src/appendix/stupid-stats.md +++ b/src/appendix/stupid-stats.md @@ -17,7 +17,7 @@ complex make project or Cargo build, etc. That could be a lot of work; rustc, like most compilers, takes a large number of command line arguments which can affect compilation in complex and interacting ways. Emulating all of this behaviour in your tool is annoying at best, especically if you are making many -of the same calls into librustc that the compiler is. +of the same calls into librustc_middle that the compiler is. The kind of things I have in mind are tools like rustdoc or a future rustfmt. These want to operate as closely as possible to real compilation, but have @@ -27,7 +27,7 @@ custom code generation phase after macro expansion, then creating a new tool should be easier than forking the compiler (and keeping it up to date as the compiler evolves). -I have gradually been trying to improve the API of librustc to make creating a +I have gradually been trying to improve the API of librustc_middle to make creating a drop-in tool easier to produce (many others have also helped improve these interfaces over the same time frame). It is now pretty simple to make a tool which is as close to rustc as you want it to be. In this tutorial I'll show @@ -73,7 +73,7 @@ checking, borrow checking, type and lifetime inference, trait selection, method selection, linting, and so forth. Most error detection is done in this phase (although parse errors are found during parsing). The 'output' of this phase is a bunch of side tables containing semantic information about the source program. -The analysis code is in [librustc](https://github.com/rust-lang/rust/tree/master/src/librustc) +The analysis code is in [librustc_middle](https://github.com/rust-lang/rust/tree/master/src/librustc_middle) and a bunch of other crates with the 'librustc_' prefix. Next is translation, this translates the AST (and all those side tables) into diff --git a/src/compiler-team.md b/src/compiler-team.md index 42f6cc0ac..3f3719f3d 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -36,8 +36,7 @@ They are held on [Zulip][zulip]. It works roughly as follows: - **Look over new regressions:** we then look for new cases where the compiler broke previously working code in the wild. Regressions are almost always marked as P-high; the major exception would be bug - fixes (though even there we often - [aim to give warnings first][procedure]). + fixes (though even there we often [aim to give warnings first][procedure]). - **Check I-nominated issues:** These are issues where feedback from the team is desired. - **Check for beta nominations:** These are nominations of things to @@ -52,7 +51,7 @@ complicated). The meeting is held over a "chat medium", currently on [zulip]. [etherpad]: https://public.etherpad-mozilla.org/p/rust-compiler-meeting -[procedure]: https://forge.rust-lang.org/rustc-bug-fix-procedure.html +[procedure]: ./bug-fix-procedure.md [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler ## Team membership diff --git a/src/tests/intro.md b/src/tests/intro.md index b70a23a6a..b47a9fdee 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -129,7 +129,7 @@ Rust's [platform tiers]). [Azure Pipelines]: https://dev.azure.com/rust-lang/rust/ [bors]: https://github.com/servo/homu [queue]: https://buildbot2.rust-lang.org/homu/queue/rust -[platform tiers]: https://forge.rust-lang.org/platform-support.html +[platform tiers]: https://forge.rust-lang.org/release/platform-support.html#rust-platform-support ## Testing with Docker images