Auto merge of #68933 - Dylan-DPC:rollup-akz13kj, r=Dylan-DPC

Rollup of 7 pull requests

Successful merges:

 - #68164 (Selectively disable sanitizer instrumentation)
 - #68413 (Add GitHub issue templates)
 - #68889 (Move the `hir().krate()` method to a query and remove the `Krate` dep node)
 - #68909 (Respect --nocapture in panic=abort test mode)
 - #68910 (Add myself to .mailmap)
 - #68919 (Remove HashStable impl for ast::Lifetime)
 - #68928 (clean up E0276 explanation)

Failed merges:

r? @ghost

.github/ISSUE_TEMPLATE/blank_issue.md

@@ -0,0 +1,4 @@
+---
+name: Blank Issue
+about: Create a blank issue.
+---

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,44 @@
+---
+name: Bug Report
+about: Create a bug report for Rust.
+labels: C-bug
+---
+<!--
+Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
+along with any information you feel relevant to replicating the bug.
+-->
+
+I tried this code:
+
+```rust
+<code>
+```
+
+I expected to see this happen: *explanation*
+
+Instead, this happened: *explanation*
+
+### Meta
+<!--
+If you're using the stable version of the compiler, you should also check if the
+bug also exists in the beta or nightly versions.
+-->
+
+`rustc --version --verbose`:
+```
+<version>
+```
+
+<!--
+Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
+environment. E.g. `RUST_BACKTRACE=1 cargo build`.
+-->
+<details><summary>Backtrace</summary>
+<p>
+
+```
+<backtrace>
+```
+
+</p>
+</details>

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,5 @@
+blank_issues_enabled: true
+contact_links:
+  - name: Rust Programming Language Forum
+    url: https://users.rust-lang.org
+    about: Please ask and answer questions about Rust here.

.github/ISSUE_TEMPLATE/ice.md

@@ -0,0 +1,52 @@
+---
+name: Internal Compiler Error
+about: Create a report for an internal compiler error in rustc.
+labels: C-bug, I-ICE, T-compiler
+---
+<!--
+Thank you for finding an Internal Compiler Error! 🧊  If possible, try to provide
+a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for
+how to create smaller examples.
+
+http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/
+
+-->
+
+### Code
+
+```
+<code>
+```
+
+
+### Meta
+<!--
+If you're using the stable version of the compiler, you should also check if the
+bug also exists in the beta or nightly versions.
+-->
+
+`rustc --version --verbose`:
+```
+<version>
+```
+
+### Error output
+
+```
+<output>
+```
+
+<!--
+Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
+environment. E.g. `RUST_BACKTRACE=1 cargo build`.
+-->
+<details><summary><strong>Backtrace</strong></summary>
+<p>
+
+```
+<backtrace>
+```
+
+</p>
+</details>
+

.github/ISSUE_TEMPLATE/tracking_issue.md

@@ -0,0 +1,58 @@
+---
+name: Tracking Issue
+about: A tracking issue for a feature in Rust.
+title: Tracking Issue for XXX
+labels: C-tracking-issue
+---
+<!--
+Thank you for creating a tracking issue! 📜 Tracking issues are for tracking a
+feature from implementation to stabilisation. Make sure to include the relevant
+RFC for the feature if it has one. Otherwise provide a short summary of the
+feature and link any relevant PRs or issues, and remove any sections that are
+not relevant to the feature.
+
+Remember to add team labels to the tracking issue.
+For a language team feature, this would e.g., be `T-lang`.
+Such a feature should also be labeled with e.g., `F-my_feature`.
+This label is used to associate issues (e.g., bugs and design questions) to the feature.
+-->
+
+This is a tracking issue for the RFC "XXX" (rust-lang/rfcs#NNN).
+The feature gate for the issue is `#![feature(FFF)]`.
+
+### About tracking issues
+
+Tracking issues are used to record the overall progress of implementation.
+They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
+A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
+Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
+
+### Steps
+<!--
+Include each step required to complete the feature. Typically this is a PR
+implementing a feature, followed by a PR that stabilises the feature. However
+for larger features an implementation could be broken up into multiple PRs.
+-->
+
+- [ ] Implement the RFC (cc @rust-lang/XXX -- can anyone write up mentoring
+      instructions?)
+- [ ] Adjust documentation ([see instructions on rustc-guide][doc-guide])
+- [ ] Stabilization PR ([see instructions on rustc-guide][stabilization-guide])
+
+[stabilization-guide]: https://rust-lang.github.io/rustc-guide/stabilization_guide.html#stabilization-pr
+[doc-guide]: https://rust-lang.github.io/rustc-guide/stabilization_guide.html#documentation-prs
+
+### Unresolved Questions
+<!--
+Include any open questions that need to be answered before the feature can be
+stabilised.
+-->
+
+XXX --- list all the "unresolved questions" found in the RFC to ensure they are
+not forgotten
+
+### Implementation history
+
+<!--
+Include a list of all the PRs that were involved in implementing the feature.
+-->

.mailmap

@@ -100,6 +100,7 @@ Graydon Hoare <graydon@pobox.com> Graydon Hoare <graydon@mozilla.com>
 Guillaume Gomez <guillaume1.gomez@gmail.com>
 Guillaume Gomez <guillaume1.gomez@gmail.com> ggomez <ggomez@ggo.ifr.lan>
 Guillaume Gomez <guillaume1.gomez@gmail.com> Guillaume Gomez <ggomez@ggo.ifr.lan>
+Hanna Kruppe <hanna.kruppe@gmail.com> <robin.kruppe@gmail.com>
 Heather <heather@cynede.net> <Cynede@Gentoo.org>
 Heather <heather@cynede.net> <Heather@cynede.net>
 Herman J. Radtke III <herman@hermanradtke.com> Herman J. Radtke III <hermanradtke@gmail.com>

src/doc/unstable-book/src/language-features/no-sanitize.md

@@ -0,0 +1,29 @@
+# `no_sanitize`
+
+The tracking issue for this feature is: [#39699]
+
+[#39699]: https://github.com/rust-lang/rust/issues/39699
+
+------------------------
+
+The `no_sanitize` attribute can be used to selectively disable sanitizer
+instrumentation in an annotated function. This might be useful to: avoid
+instrumentation overhead in a performance critical function, or avoid
+instrumenting code that contains constructs unsupported by given sanitizer.
+
+The precise effect of this annotation depends on particular sanitizer in use.
+For example, with `no_sanitize(thread)`, the thread sanitizer will no longer
+instrument non-atomic store / load operations, but it will instrument atomic
+operations to avoid reporting false positives and provide meaning full stack
+traces.
+
+## Examples
+
+``` rust
+#![feature(no_sanitize)]
+
+#[no_sanitize(address)]
+fn foo() {
+  // ...
+}
+```

src/librustc/arena.rs

@@ -127,7 +127,7 @@ macro_rules! arena_types {
             [] tys: rustc::ty::TyS<$tcx>,
 
             // HIR types
-            [few] hir_forest: rustc::hir::map::Forest<$tcx>,
+            [few] hir_krate: rustc_hir::Crate<$tcx>,
             [] arm: rustc_hir::Arm<$tcx>,
             [] attribute: syntax::ast::Attribute,
             [] block: rustc_hir::Block<$tcx>,

src/librustc/dep_graph/dep_node.rs

@@ -35,7 +35,7 @@
 //! "infer" some properties for each kind of `DepNode`:
 //!
 //! * Whether a `DepNode` of a given kind has any parameters at all. Some
-//!   `DepNode`s, like `Krate`, represent global concepts with only one value.
+//!   `DepNode`s, like `AllLocalTraitImpls`, represent global concepts with only one value.
 //! * Whether it is possible, in principle, to reconstruct a query key from a
 //!   given `DepNode`. Many `DepKind`s only require a single `DefId` parameter,
 //!   in which case it is possible to map the node's fingerprint back to the
@@ -400,19 +400,6 @@ rustc_dep_node_append!([define_dep_nodes!][ <'tcx>
     // We use this for most things when incr. comp. is turned off.
     [] Null,
 
-    // Represents the `Krate` as a whole (the `hir::Krate` value) (as
-    // distinct from the krate module). This is basically a hash of
-    // the entire krate, so if you read from `Krate` (e.g., by calling
-    // `tcx.hir().krate()`), we will have to assume that any change
-    // means that you need to be recompiled. This is because the
-    // `Krate` value gives you access to all other items. To avoid
-    // this fate, do not call `tcx.hir().krate()`; instead, prefer
-    // wrappers like `tcx.visit_all_items_in_krate()`.  If there is no
-    // suitable wrapper, you can use `tcx.dep_graph.ignore()` to gain
-    // access to the krate, but you must remember to add suitable
-    // edges yourself for the individual items that you read.
-    [eval_always] Krate,
-
     // Represents the body of a function or method. The def-id is that of the
     // function/method.
     [eval_always] HirBody(DefId),

src/librustc/hir/map/collector.rs

@@ -223,12 +223,9 @@ impl<'a, 'hir> NodeCollector<'a, 'hir> {
             (commandline_args_hash, crate_disambiguator.to_fingerprint()),
         );
 
-        let (_, crate_hash) = input_dep_node_and_hash(
-            self.dep_graph,
-            &mut self.hcx,
-            DepNode::new_no_params(DepKind::Krate),
-            crate_hash_input,
-        );
+        let mut stable_hasher = StableHasher::new();
+        crate_hash_input.hash_stable(&mut self.hcx, &mut stable_hasher);
+        let crate_hash: Fingerprint = stable_hasher.finish();
 
         let svh = Svh::new(crate_hash.to_smaller_hash());
         (self.map, svh)

src/librustc/hir/map/hir_id_validator.rs

@@ -12,7 +12,7 @@ pub fn check_crate(hir_map: &Map<'_>) {
 
     let errors = Lock::new(Vec::new());
 
-    par_iter(&hir_map.krate().modules).for_each(|(module_id, _)| {
+    par_iter(&hir_map.krate.modules).for_each(|(module_id, _)| {
         let local_def_id = hir_map.local_def_id(*module_id);
         hir_map.visit_item_likes_in_module(
             local_def_id,