Update from upstream

.editorconfig

@@ -0,0 +1,21 @@
+# EditorConfig helps developers define and maintain consistent
+# coding styles between different editors and IDEs
+# editorconfig.org
+
+root = true
+
+[*]
+end_of_line = lf
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = true
+indent_style = space
+indent_size = 4
+
+[*.md]
+# double whitespace at end of line
+# denotes a line break in Markdown
+trim_trailing_whitespace = false
+
+[*.yml]
+indent_size = 2

.gitattributes

@@ -3,8 +3,9 @@
 * text=auto eol=lf
 *.cpp rust
 *.h rust
-*.rs rust
+*.rs rust diff=rust
 *.fixed linguist-language=Rust
+*.mir linguist-language=Rust
 src/etc/installer/gfx/* binary
 *.woff binary
 src/vendor/** -text

.github/ISSUE_TEMPLATE/config.yml

@@ -1,5 +1,8 @@
 blank_issues_enabled: true
 contact_links:
-  - name: Rust Programming Language Forum
+  - name: Question
     url: https://users.rust-lang.org
-    about: Please ask and answer questions about Rust here.
+    about: Please ask and answer questions about Rust on the user forum.
+  - name: Feature Request
+    url: https://internals.rust-lang.org/
+    about: Please discuss language feature requests on the internals forum.

.github/ISSUE_TEMPLATE/diagnostics.md

@@ -0,0 +1,46 @@
+---
+name: Diagnostic issue
+about: Create a bug report or feature request for a change to `rustc`'s error output
+labels: A-diagnostics, T-compiler
+---
+<!--
+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.
+
+If you cannot produce a minimal reproduction case (something that would work in
+isolation), please provide the steps or even link to a repository that causes
+the problematic output to occur. 
+-->
+
+Given the following code: <!-- Please provide a link to play.rust-lang.org -->
+
+```rust
+<code>
+```
+
+The current output is:
+
+```
+<rustc output>
+```
+
+<!-- The following is not always necessary. -->
+Ideally the output should look like:
+
+```
+<proposed output>
+```
+
+<!--
+If the problem is not self-explanatory, please provide a rationale for the
+change.
+-->
+
+<!--
+If dramatically different output is caused by small changes, consider also
+adding them here.
+
+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. The output might also be
+different depending on the Edition.
+-->

.github/ISSUE_TEMPLATE/library_tracking_issue.md

@@ -0,0 +1,83 @@
+---
+name: Library Tracking Issue
+about: A tracking issue for an unstable library feature.
+title: Tracking Issue for XXX
+labels: C-tracking-issue, T-libs
+---
+<!--
+Thank you for creating a tracking issue!
+
+Tracking issues are for tracking a feature from implementation to stabilization.
+
+Make sure to include the relevant RFC for the feature if it has one.
+
+If the new feature is small, it may be fine to skip the RFC process. In that
+case, you can use use `issue = "none"` in your initial implementation PR. The
+reviewer will ask you to open a tracking issue if they agree your feature can be
+added without an RFC.
+-->
+
+Feature gate: `#![feature(...)]`
+
+This is a tracking issue for ...
+
+<!--
+Include a short description of the feature.
+-->
+
+### Public API
+
+<!--
+For most library features, it'd be useful to include a summarized version of the public API.
+(E.g. just the public function signatures without their doc comments or implementation.)
+-->
+
+```rust
+// core::magic
+
+pub struct Magic;
+
+impl Magic {
+    pub fn magic(self);
+}
+```
+
+### Steps / History
+
+<!--
+For larger features, more steps might be involved.
+If the feature is changed later, please add those PRs here as well.
+-->
+
+- [ ] Implementation: #...
+- [ ] Final commenting period (FCP)
+- [ ] Stabilization PR
+
+<!--
+Once the feature has gone through a few release cycles and there are no
+unresolved questions left, the feature might be ready for stabilization.
+
+If this feature didn't go through the RFC process, a final commenting period
+(FCP) is always needed before stabilization. This works as follows:
+
+A library team member can kick off the stabilization process, at which point
+the rfcbot will ask all the team members to verify they agree with
+stabilization. Once enough members agree and there are no concerns, the final
+commenting period begins: this issue will be marked as such and will be listed
+in the next This Week in Rust newsletter. If no blocking concerns are raised in
+that period of 10 days, a stabilzation PR can be opened by anyone.
+-->
+
+### Unresolved Questions
+
+<!--
+Include any open questions that need to be answered before the feature can be
+stabilised. If multiple (unrelated) big questions come up, it can be a good idea
+to open a separate issue for each, to make it easier to keep track of the
+discussions.
+
+It's useful to link any relevant discussions and conclusions (whether on GitHub,
+Zulip, or the internals forum) here.
+-->
+
+- None yet.

.github/ISSUE_TEMPLATE/regression.md

@@ -0,0 +1,68 @@
+---
+name: Regression
+about: Report something that unexpectedly changed between Rust versions.
+labels: C-bug regression-untriaged
+---
+<!--
+Thank you for filing a regression report! 🐛 A regression is something that changed between versions of Rust but was not supposed to.
+
+Please provide a short summary of the regression, along with any information you feel is relevant to replicate it.
+-->
+
+### Code
+
+I tried this code:
+
+```rust
+<code>
+```
+
+I expected to see this happen: *explanation*
+
+Instead, this happened: *explanation*
+
+### Version it worked on
+
+<!--
+Provide the most recent version this worked on, for example:
+
+It most recently worked on: Rust 1.47
+-->
+
+It most recently worked on: <!-- version -->
+
+### Version with regression
+
+<!--
+Provide the version you are using that has the regression.
+-->
+
+`rustc --version --verbose`:
+```
+<version>
+```
+
+<!--
+Did the compiler crash? If so, please provide a backtrace.
+-->
+
+### Backtrace
+<!--
+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>
+
+<!--
+If you know when this regression occurred, please add a line like below, replacing `{channel}` with one of stable, beta, or nightly.
+
+@rustbot modify labels: +regression-from-stable-to-{channel} -regression-untriaged
+-->

.github/ISSUE_TEMPLATE/tracking_issue.md

@@ -5,6 +5,8 @@ title: Tracking Issue for XXX
 labels: C-tracking-issue
 ---
 <!--
+NOTE: For library features, please use the "Library Tracking Issue" template instead.
+
 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
@@ -23,7 +25,7 @@ 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.
+They are also used 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.