Auto merge of #68623 - Zoxc:lld, r=Mark-Simulacrum

Add an option to use LLD to link the compiler on Windows platforms

Based on https://github.com/rust-lang/rust/pull/68609.

Using LLD is good way to improve compile times on Windows since `link.exe` is quite slow. The time for `x.py build --stage 1 src/libtest` goes from 0:12:00 to 0:08:29. Compile time for `rustc_driver` goes from 226.34s to 18.5s. `rustc_macros` goes from 28.69s to 7.7s. The size of `rustc_driver` is also reduced from 83.3 MB to 78.7 MB.

r? @Mark-Simulacrum

More comments

Add some comments

Auto merge of #68975 - Dylan-DPC:rollup-jzab8oh, r=Dylan-DPC

Rollup of 7 pull requests

Successful merges:

 - #68718 (Move `rustc_hir::def_id` to `rustc_span::def_id`)
 - #68834 (Fix and test implementation of BTreeMap's first/last_entry, pop_first/last)
 - #68857 (perf: Reduce Vec allocations in normalization by passing &mut Vec)
 - #68918 (Don't use the word "unwrap" to describe "unwrap" methods)
 - #68946 (Mark several functions and methods in core::cmp as #[must_use])
 - #68958 (Clean up E0277 and E0282 explanations)
 - #68960 (codegen: misc cleanups around debuginfo scopes and locations.)

Failed merges:

r? @ghost

Auto merge of #68689 - estebank:where-clause-sugg-missing-fn, r=varkor

When suggesting associated fn with type parameters, include in the structured suggestion

Address #50734.

```
error[E0046]: not all trait items implemented, missing: `foo`, `bar`, `baz`
  --> file.rs:14:1
   |
14 | impl TraitA<()> for S {
   | ^^^^^^^^^^^^^^^^^^^^^ missing `foo`, `bar`, `baz` in implementation
   |
   = help: implement the missing item: `fn foo<T>(_: T) -> Self where T: TraitB, TraitB::Item = A { unimplemented!() }`
   = help: implement the missing item: `fn bar<T>(_: T) -> Self { unimplemented!() }`
   = help: implement the missing item: `fn baz<T>(_: T) -> Self where T: TraitB, <T as TraitB>::Item: std::marker::Copy { unimplemented!() }`
```

It doesn't work well for associated types with `ty::Predicate::Projection`s as we need to resugar `T: Trait, Trait::Assoc = K` → `T: Trait<Assoc = K>`.

review comment

Auto merge of #68376 - Centril:move-ref-patterns, r=matthewjasper

Initial implementation of `#![feature(move_ref_pattern)]`

Following up on #45600, under the gate `#![feature(move_ref_pattern)]`, `(ref x, mut y)` is allowed subject to restrictions necessary for soundness. The match checking implementation and tests for `#![feature(bindings_after_at)]` is also adjusted as necessary.

Closes #45600.
Tracking issue: #68354.

r? @matthewjasper

Rollup merge of #68960 - eddyb:llvm-dbg-cleanup, r=nagisa

codegen: misc cleanups around debuginfo scopes and locations.

See each commit message. Most of these seem to be leftovers from the transition to MIR codegen.

r? @nagisa cc @bjorn3

Rollup merge of #68958 - GuillaumeGomez:clean-up-e0277-e0282, r=Dylan-DPC

Clean up E0277 and E0282 explanations

r? @Dylan-DPC

Rollup merge of #68946 - mjbshaw:must_use, r=mjbshaw

Mark several functions and methods in core::cmp as #[must_use]

These functions and methods aren't mutating functions and ignoring the result of them is likely a bug in the user's code.

Rollup merge of #68918 - brson:unwrapdoc, r=Dylan-DPC

Don't use the word "unwrap" to describe "unwrap" methods

It's tautological, and "unwrap" is essentially Rust-specific jargon.

I was teaching a newbie some Rust, and doing the usual hand-waving about error handling using unwrap. They asked what 'unwrap' means. I said look it up in the docs. The docs read (paraphrased) "unwrap unwraps". I was embarrassed.

This changes all the Option/Result functions with unwrapping behavior to use a variation on a single description:

> "Returns the contained `Some/Ok` value [or ...]."

It also renames the closure of `Result::unwrap_or_else` to `default` for consistency with `Option`, and perhaps makes a few other small tweaks.

Previous: https://github.com/rust-lang/rust/pull/68849

Rollup merge of #68857 - Marwes:allocations, r=matthewjasper

perf: Reduce Vec allocations in normalization by passing &mut Vec

Complicates the code a bit but allocation/freeing were a few percent of the overall runtime in trait heavy code.

Rollup merge of #68834 - ssomers:btree_first_last_fix68829, r=KodrAus

Fix and test implementation of BTreeMap's first/last_entry, pop_first/last

Properly implement and test `first_entry` & `last_entry` to fix problem report #68829

Rollup merge of #68718 - Aaron1011:move-def-hir-span, r=petrochenkov

Move `rustc_hir::def_id` to `rustc_span::def_id`

This will allow `HygieneData` to refer to `DefId` and `DefIndex`, which
will enable proper serialization of Span hygiene information.

This also reduces the number of things imported from `rustc_hir`, which
might make it easier to remove dependencies on it.

Move librustc_hir/def_id.rs to librustc_span/def_id.rs

For noww, librustc_hir re-exports the `def_id` module from
librustc_span, so the rest of rustc can continue to reference
rustc_hir::def_id

Auto merge of #68802 - eddyb:debuginfo-there-can-only-be-one-arg, r=nagisa

rustc_codegen_ssa: don't treat inlined variables as debuginfo arguments.

Fixes #67586 by limiting `ArgumentVariable` special-casing to `VarDebugInfo` entries that are in `OUTERMOST_SOURCE_SCOPE`, i.e. the function's own argument scope.
That excludes `VarDebugInfo` from inlined callees, which can also point to the caller's argument locals.

This is a snippet from the optimized MIR (including inlining) of the testcase:
```rust
fn  foo(_1: usize) -> usize {
    debug bar => _1;                     // in scope 0 at ./example.rs:2:12: 2:15
    let mut _0: usize;                   // return place in scope 0 at ./example.rs:2:27: 2:32
    scope 1 {
        debug x => _1;                   // in scope 1 at /rustc/9ed29b6ff6aa2e048b09c27af8f62ee3040bdb37/src/libcore/convert/mod.rs:106:26: 106:27
    }
```
`scope 1` is from inlining the `identity` call, and `debug x => _1;` comes from the body of `core::convert::identity`, so they are now ignored for the purposes of determining the `ArgumentVariable` debuginfo associated to `_1`.

Reduce Vec allocations in normalization by passing &mut Vec

Mark several functions and methods in core::cmp as #[must_use]

Auto merge of #68452 - msizanoen1:riscv-abi, r=nagisa,eddyb

Implement proper C ABI lowering for RISC-V

This is necessary for full RISC-V psABI compliance when passing argument across C FFI boundary.

cc @lenary

rustc_codegen_ssa: remove unnecessary source_locations_enabled.

rustc_codegen_llvm: remove InternalDebugLocation and simplify dbg_var_addr.

rustc_codegen_llvm: remove unnecessary special-casing of root scopes' children.

Clean up E0277 and E0282 explanations

Auto merge of #68443 - eddyb:abi-compat-enum, r=nagisa

rustc_target: treat enum variants like union members, in call ABIs.

Fixes #68190, by handling non-C-like `enum`s as-if they were an `union` of `struct`s, in call ABIs.
Tests were provided by @sw17ch, from theirs and @bitwalker's original examples.

cc @nagisa @rkruppe

test: use `all: $(call NATIVE_STATICLIB,test)` to build a C lib.

test: address comments and pacify the merciless tidy.

rustc_target: treat enum variants like union members, in call ABIs.

rustc_target: switch homogeneous_aggregate to returning Result.

Add non-C-like enumeration tests on Rust->C calls to the abi-sysv64-arg-passing test.

Two test cases where Rust calls C using enums by value

One calls into C functions passing non-c-like enumerations by
value. The other calls into C expecting non-C-like enumerations as
returns.

These test cases are based on the tests provided by @bitwalker on
issue #68190. The original tests were provided at:
https://github.com/bitwalker/rust_non_c_like_enums_issue/tree/2688d5c672bd4e289085fcdf1c6110e99e7e8ab1

Add similar examples that work to each test.

Add a test that demonstrates an incorrect return value when calling into rust with non-c-like-enums.

Add a test that demonstrates a segfault when calling into rust with non-c-like-enum.

Auto merge of #68358 - matthewjasper:spec-fix, r=nikomatsakis

Remove some unsound specializations

This removes the unsound and exploitable specializations in the standard library

* The `PartialEq` and `Hash` implementations for  `RangeInclusive` are changed to avoid specialization.
* The `PartialOrd` specialization for slices now specializes on a limited set of concrete types.
* Added some tests for the soundness problems.

Auto merge of #65232 - nikomatsakis:lazy-norm-anon-const-push-2, r=matthewjasper

replace the leak check with universes, take 2

This PR is an attempt to revive the "universe-based region check", which is an important step towards lazy normalization. Unlike before, we also modify the definition of `'empty` so that it is indexed by a universe. This sidesteps some of the surprising effects we saw before -- at the core, we no longer think that `exists<'a> { forall<'b> { 'b: 'a } }` is solveable. The new region lattice looks like this:

```
static ----------+-----...------+       (greatest)
|                |              |
early-bound and  |              |
free regions     |              |
|                |              |
scope regions    |              |
|                |              |
empty(root)   placeholder(U1)   |
|            /                  |
|           /         placeholder(Un)
empty(U1) --         /
|                   /
...                /
|                 /
empty(Un) --------                      (smallest)
```
This PR has three effects:

* It changes a fair number of error messages, I think for the better.
* It fixes a number of bugs. The old algorithm was too conservative and caused us to reject legal subtypings.
* It also causes two regressions (things that used to compile, but now do not).
    * `coherence-subtyping.rs` gets an additional error. This is expected.
    * `issue-57639.rs` regresses as before, for the reasons covered in #57639.

Both of the regressions stem from the same underlying property: without the leak check, the instantaneous "subtype" check is not able to tell whether higher-ranked subtyping will succeed or not. In both cases, we might be able to fix the problem by doing a 'leak-check like change' at some later point (e.g., as part of coherence).

This is a draft PR because:

* I didn't finish ripping out the leak-check completely.
* We might want to consider a crater run before landing this.
* We might want some kind of design meeting to cover the overall strategy.
* I just remembered I never finished 100% integrating this into the canonicalization code.
* I should also review what happens in NLL region checking -- it probably still has a notion of bottom (empty set).

r? @matthewjasper

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

Rollup merge of #68928 - GuillaumeGomez:cleanup-e0276, r=Dylan-DPC

clean up E0276 explanation

r? @Dylan-DPC

Rollup merge of #68919 - Zoxc:ast-lifetime, r=nikomatsakis

Remove HashStable impl for ast::Lifetime

Rollup merge of #68910 - hanna-kruppe:master, r=Mark-Simulacrum

Add myself to .mailmap

Rollup merge of #68909 - tmandry:panic-abort-nocapture, r=alexcrichton

Respect --nocapture in panic=abort test mode

r? @alexcrichton

Rollup merge of #68889 - Zoxc:hir-krate, r=eddyb

Move the `hir().krate()` method to a query and remove the `Krate` dep node

r? @eddyb cc @michaelwoerister

Rollup merge of #68413 - XAMPPRocky:master, r=Mark-Simulacrum

Add GitHub issue templates

This PR adds GitHub's issue templates to the repository. Adding templates for two of the most common issues we create on the repository. We could add more specific templates (e.g. ICEs) depending on the response to initial templates. I've included a screenshot of what it looks like, and people can also try out the UI and specific templates, by going to [`XAMPPRocky/rust`](https://github.com/XAMPPRocky/rust/issues/new/choose).

<img width="1115" alt="Screenshot 2020-01-21 at 13 57 46" src="https://user-images.githubusercontent.com/4464295/72807027-c51baa00-3c56-11ea-8a4c-98238489b345.png">

Rollup merge of #68164 - tmiasko:no-sanitize, r=nikomatsakis

Selectively disable sanitizer instrumentation

Add `no_sanitize` attribute that allows to opt out from sanitizer
instrumentation in an annotated function.

Auto merge of #68930 - RalfJung:miri, r=RalfJung

update miri

Cc @oli-obk r? @ghost

Fixes https://github.com/rust-lang/rust/issues/68878

update miri

clean up E0276 explanation

Remove HashStable impl for ast::Lifetime

Auto merge of #68499 - ssomers:btree_search_tidying, r=Mark-Simulacrum

BtreeMap range_search spruced up

#39457 created a lower level entry point for `range_search` to operate on, but it's really not hard to move it up a level of abstraction, making it somewhat shorter and reusing existing unsafe code (`new_edge` is unsafe although it is currently not tagged as such).

Benchmark added. Comparison says there's no real difference:
```
>cargo benchcmp old3.txt new3.txt --threshold 5
 name                                           old3.txt ns/iter  new3.txt ns/iter  diff ns/iter   diff %  speedup
 btree::map::find_seq_100                       19                21                           2   10.53%   x 0.90
 btree::map::range_excluded_unbounded           3,117             2,838                     -279   -8.95%   x 1.10
 btree::map::range_included_unbounded           1,768             1,871                      103    5.83%   x 0.94
 btree::set::intersection_10k_neg_vs_10k_pos    35                37                           2    5.71%   x 0.95
 btree::set::intersection_staggered_100_vs_10k  2,488             2,314                     -174   -6.99%   x 1.08
 btree::set::is_subset_10k_vs_100               3                 2                           -1  -33.33%   x 1.50
```

r? @Mark-Simulacrum

Don't use the word 'unwrap' to describe core unwrapping functions

It's tautological, and Rust-specific Jargon.

This changes various Option/Result methods to consistently describe unwrapping
behavior using the words "return", "contain", "consume".

It also renames the closure argument of `Return::unwrap_or_else` to `default` to
be consistent with `Option`.

Lift range_search up one level of abstraction

Auto merge of #68907 - Dylan-DPC:rollup-osm5e8o, r=Dylan-DPC

Rollup of 6 pull requests

Successful merges:

 - #67359 (Rename -Zexternal-macro-backtrace to -Zmacro-backtrace and clean up implementation.)
 - #68524 (Generator Resume Arguments)
 - #68791 (implement proper linkchecker hardening)
 - #68886 (Mark fn map_or() as eagerly evaluated.)
 - #68888 (error code examples: replace some more ignore with compile_fail)
 - #68894 (Update E0565 examples)

Failed merges:

r? @ghost

Create benchmarks for BTreeMap::range

Add myself to .mailmap

Respect --nocapture in panic=abort test mode

Rollup merge of #68894 - JohnTitor:update-e0565, r=Dylan-DPC

Update E0565 examples

Fixes #68892

r? @GuillaumeGomez

Rollup merge of #68888 - tspiteri:ignore-to-compile_fail, r=petrochenkov

error code examples: replace some more ignore with compile_fail

Now that #68664 has been merged and `compile_fail` attempts a full build rather than `--emit=metadata`, these errors should be caught by `compile_fail` and do not need to be ignored.

Rollup merge of #68886 - tom-a-wagner:master, r=Mark-Simulacrum

Mark fn map_or() as eagerly evaluated.

In the docs for option.rs and result.rs, it is noted for all *_or()
functions that they are eagerly evaluated, except for the map_or()
function.
This commit adds this missing documentation to the two files.

Closes #68866

Rollup merge of #68791 - mark-i-m:proper-linkcheck, r=ehuss,JohnTitor

implement proper linkchecker hardening

r? @JohnTitor

This implements proper linkcheck filtering... we might need to fiddle with a bit to adjust what is or isn't filtered, but this seems to work reasonable locally.

Rollup merge of #68524 - jonas-schievink:generator-resume-arguments, r=Zoxc

Generator Resume Arguments

cc https://github.com/rust-lang/rust/issues/43122 and https://github.com/rust-lang/rust/issues/56974

Blockers:
* [x] Fix miscompilation when resume argument is live across a yield point (https://github.com/rust-lang/rust/pull/68524#issuecomment-578459069)
* [x] Fix 10% compile time regression in `await-call-tree` benchmarks (https://github.com/rust-lang/rust/pull/68524#issuecomment-578487162)
  * [x] Fix remaining 1-3% regression (https://github.com/rust-lang/rust/pull/68524#issuecomment-579566255) - resolved (https://github.com/rust-lang/rust/pull/68524#issuecomment-581144901)
* [x] Make dropck rules account for resume arguments (https://github.com/rust-lang/rust/pull/68524#issuecomment-578541137)

Follow-up work:
* Change async/await desugaring to make use of this feature
* Rewrite [`box_region.rs`](https://github.com/rust-lang/rust/blob/3d8778d767f0dde6fe2bc9459f21ead8e124d8cb/src/librustc_data_structures/box_region.rs) to use resume arguments (this shows up in profiles too)

Rollup merge of #67359 - eddyb:macro-backtrace-all-the-same, r=petrochenkov

Rename -Zexternal-macro-backtrace to -Zmacro-backtrace and clean up implementation.

This is my attempt at dealing with https://github.com/rust-lang/rust/pull/66364#issuecomment-565517232, although I'm not sure it's the least disruptive one.

The behavior of `-Zexternal-macro-backtrace` was already to enable full macro backtraces for *all* macros, the only part of it that was specific to cross-crate macros was showing this when *not used*:
```
note: this error originates in a macro outside of the current crate
  (in Nightly builds, run with -Z external-macro-backtrace for more info)
```

After this PR:
* the flag is renamed to `-Zmacro-backtrace`
  * do we need to have a deprecation period? cc @rust-lang/compiler
* the message informing you about the flag is always shown when an expansion of a bang macro/attribute/derive is involved, not just cross-crate ones
  * this accounts for most of the changes in tests
  * we could perhaps only show it for the bang macro case? feels odd for derives
* `fix_multispans_in_std_macros` is split into `fix_multispans_in_extern_macros` and `render_multispans_macro_backtrace`
  * this roughly reverts the non-behavioral parts of #46605, which combined the two functionalities
  * not sure where the old `std_macros` name came from, perhaps the `<std macros>` synthetic "file"? even then, odd that `std` specifically was mentioned
* `render_multispan_macro_backtrace`, by default (i.e. without `-Zmacro-backtrace`), hides the `in this macro invocation` label specifically to avoid redundancy in the diagnostic
  * that is, showing the macro use site is only useful when the diagnostic is inside the macro definition and the user can't otherwise tell which use site it applies to, not when the diagnostic is at/inside the use site already (which would make the label redundant)
  * before, it was only checking for the situation in which a cross-crate macro *definition* span would be replaced with the invocation span, which both made the connection to redundancy unobvious, and didn't help with other redundancy (e.g. when the diagnostic was pointing to an argument inside the macro invocation)
  * this accounts for the remaining test changes, which I've first noticed in https://github.com/rust-lang/rust/pull/66364#discussion_r356135967 but only later understood as part of this PR (hence the "redundancy" descriptions)

This PR is not needed for #66364, but it would help, as after this PR there's only one `.span_to_filename(...).is_macros()` check (i.e. for `<... macros>` synthetic "files") left in `rustc_errors`, and it's much more self-contained.

r? @petrochenkov

make lint warn by default

lint impls that will become incoherent when leak-check is removed

add the ability to skip leak check within a snapshot

The intention is that coherence code will skip the leak check and
determine whether two impls *would have* overlapped, and then issue a
warning.

apply various formatting nits

use derive(Debug) for TypeTrace

index ReEmpty by universe

We now make `'empty` indexed by a universe index, resulting
in a region lattice like this:

```
static ----------+-----...------+       (greatest)
|                |              |
early-bound and  |              |
free regions     |              |
|                |              |
scope regions    |              |
|                |              |
empty(root)   placeholder(U1)   |
|            /                  |
|           /         placeholder(Un)
empty(U1) --         /
|                   /
...                /
|                 /
empty(Un) --------                      (smallest)
```

Therefore, `exists<A> { forall<B> { B: A } }` is now unprovable,
because A must be at least Empty(U1) and B is placeholder(U2), and hence
the two regions are unrelated.

integrate the `sub_free_regions` code so we have only one copy of it

don't mention specific region numbers in the ~ERROR message

add a `IsEmpty` for use in verified bounds

We currently have a kind of arbitrary check for `Verify` conditions
which says that if the "test region" is `'empty`, then the check
passes. This was added to fix #42467 -- it happens to be correct for
the purposes that we use verify bounds for, but it doesn't feel
generally correct. Replace with a more principled test.

do not limit NiceRegionError to SubSupConflict or ConcreteFailure

tests: add a revision to macro_backtrace without -Zmacro-backtrace.

rustc_macros: don't limit the -Zmacro-backtrace suggestion to extern macros.

rustc_errors: hide "in this macro invocation" when redundant, more explicitly.

rustc_errors: deduplicate the -Zmacro-backtrace suggestion message.

rustc: rename -Zexternal-macro-backtrace to -Zmacro-backtrace.

rustc_errors: split macro backtrace rendering from <*macros> hacks.

Mark fn map_or() as eagerly evaluated.

In the docs for option.rs and result.rs, it is noted for all *_or()
functions that they are eagerly evaluated, except for the map_or()
function.
This commit adds this missing documentation to the two files.

Make `krate` private

Auto merge of #68893 - Dylan-DPC:rollup-3f2421a, r=Dylan-DPC

Rollup of 9 pull requests

Successful merges:

 - #68691 (Remove `RefCell` usage from `ObligationForest`.)
 - #68751 (Implement `unused_parens` for `const` and `static` items)
 - #68788 (Towards unified `fn` grammar)
 - #68837 (Make associated item collection a query)
 - #68842 (or_patterns: add regression test for #68785)
 - #68844 (use def_path_str for missing_debug_impls message)
 - #68845 (stop using BytePos for computing spans in librustc_parse/parser/mod.rs)
 - #68869 (clean up E0271 explanation)
 - #68880 (Forbid using `0` as issue number)

Failed merges:

r? @ghost

Update E0565 examples

Rollup merge of #68880 - JohnTitor:issue-non-zero, r=Dylan-DPC

Forbid using `0` as issue number

Fixes #67496

r? @Centril

Rollup merge of #68869 - GuillaumeGomez:err-explanation-e0271, r=Dylan-DPC

clean up E0271 explanation

r? @Dylan-DPC

Rollup merge of #68845 - dwrensha:fix-68783, r=estebank

stop using BytePos for computing spans in librustc_parse/parser/mod.rs

Computing spans using logic such as `self.token.span.lo() + BytePos(1)` can cause internal compiler errors like #68730 when non-ascii characters are given as input.

#68735 partially addressed this problem, but only for one case. Moreover, its usage of `next_point()` does not actually align with what `bump_with()` expects. For example, given the token `>>=`, we should pass the span consisting of the final two characters `>=`, but `next_point()` advances the span beyond the end of the `=`.

This pull request instead computes the start of the new span by doing `start_point(self.token.span).hi()`. This matches `self.token.span.lo() + BytePos(1)` in the common case where the characters are ascii, and it gracefully handles multibyte characters.

Fixes #68783.

Rollup merge of #68844 - euclio:debug-impl-def-path, r=petrochenkov

use def_path_str for missing_debug_impls message

The lint message will now use the full, correct path to the `Debug`
trait, even in `no_std`.

Rollup merge of #68842 - Centril:issue-68785, r=estebank

or_patterns: add regression test for #68785

Fixes https://github.com/rust-lang/rust/issues/68785.

(Fixed by https://github.com/rust-lang/rust/pull/67668.)

cc https://github.com/rust-lang/rust/issues/54883
r? @estebank

Rollup merge of #68837 - jonas-schievink:assoc-item-lookup-2, r=estebank

Make associated item collection a query

Before this change, every time associated items were iterated over (which rustc does *a lot* – this can probably be further optimized), there would be N+1 queries to fetch all assoc. items. Now there's just one after they've been computed once.

Rollup merge of #68788 - Centril:unified-fn-bodies, r=petrochenkov

Towards unified `fn` grammar

Part of https://github.com/rust-lang/rust/pull/68728.

- Syntactically, `fn` items in `extern { ... }` blocks can now have bodies (`fn foo() { ... }` as opposed to `fn foo();`). As above, we use semantic restrictions instead.

- Syntactically, `fn` items in free contexts (directly in a file or a module) can now be without bodies (`fn foo();` as opposed to `fn foo() { ... }`. As above, we use semantic restrictions instead, including for non-ident parameter patterns.

- We move towards unifying the `fn` front matter; this is fully realized in https://github.com/rust-lang/rust/pull/68728.

r? @petrochenkov

Rollup merge of #68751 - Tyg13:unused_parens_const_static, r=Centril

Implement `unused_parens` for `const` and `static` items

Fixes #67942

Rollup merge of #68691 - nnethercote:rm-RefCell-from-ObligationForest, r=nikomatsakis

Remove `RefCell` usage from `ObligationForest`.

It's not needed.

This doesn't affect performance, it just simplifies the code a little.

r? @nikomatsakis

error code examples: replace some more ignore with compile_fail

Now that compile_fail attempts a full build rather than
--emit=metadata, these errors should be caught by compile_fail and do
not need to be ignored.

Ignore panic-drops-resume.rs on wasm/emscripten

It does not have unwinding support

Comment tweaks

Remove the `Forest` type

Move the `krate` method to Hir and remove the Krate dep node

Clarify comment about `_2` living across a yield

Simplify implicit resume argument

Add a `hir_krate` query

Add a Hir wrapper type

Auto merge of #68664 - tspiteri:no_run-complete-build, r=nikomatsakis

rustdoc: attempt full build for compile_fail test

Some code fails when doing a full build but does not fail when only emitting metadata. This commit makes sure compile_fail tests for such code behave as expected, that is, the test succeeds because the compilation fails.

Fixes #67771.

Forbid using `0` as issue number