don't ICE on large files

This is an extremely marginal error, so the cost of properly threading
`Handler` everywhere just not seemed justified. However, it's useful
to panic when we create a file, and not when we slice strings with
overflown indexes somewhere in the guts of the compiler.

For this reason, while we provide safe `try_new_source_file`, we don't
change the existing public interface and just panic more or less
cleanly.

Auto merge of #61892 - rijenkii:master, r=Centril

weird-exprs: if if if if

The `if` keyword can be chained as long as there are enough `{...} else {...}` following, and they all return a `bool` (not required for the last one).
`if` expression can be also put inside a `match` arm guard, thus making the whole thing a little bit more confusing.

Discovered this clusterfunk while reading the reference because I have nothing better to do.

Auto merge of #61347 - Centril:stabilize-underscore_const_names, r=petrochenkov

Stabilize underscore_const_names in 1.37.0

You are now permitted to write:

```rust
const _: $type_expression = $term_expression;
```

That is, we change the [grammar of items](https://github.com/rust-lang-nursery/wg-grammar/blob/9d1984d7ae8d6576f943566539a31a5800644c57/grammar/item.lyg#L3-L42), as written in [the *`.lyg`* notation](https://github.com/rust-lang/gll/tree/263bf161dad903e67aa65fc591ced3cab18afa2a#grammar), from:

```java
Item = attrs:OuterAttr* vis:Vis? kind:ItemKind;
ItemKind =
  | ...
  | Const:{ "const" name:IDENT ":" ty:Type "=" value:Expr ";" }
  | ...
  ;
```

into:

```java
Item = attrs:OuterAttr* vis:Vis? kind:ItemKind;
ItemKind =
  | ...
  | Const:{ "const" name:IdentOrUnderscore ":" ty:Type "=" value:Expr ";" }
  | ...
  ;

IdentOrUnderscore =
  | Named:IDENT
  | NoName:"_"
  ;
```

r? @petrochenkov

Auto merge of #61881 - glaubitz:sparc64-ffi-abi, r=petrochenkov

librustc_codegen_llvm: Use repr(transparent) for bitflags over repr(C…

…) (#61306)

In order to make sure that Rust's bitflags types are passed the same way in the Rust ABI as they are in the C ABI, we need to use the attribute repr(transparent) over the repr(C) attribute for the single-field bitflags structs in in order to prevent ABI mismatches. Thanks to Michael Karcher for finding this bug.

Auto merge of #61754 - nikomatsakis:trait-caching-perf-3, r=pnkfelix

create a "provisional cache" to restore performance in the case of cycles

Introduce a "provisional cache" that caches the results of auto trait resolutions but keeps them from entering the *main* cache until everything is ready. This turned out a bit more complex than I hoped, but I don't see another short term fix -- happy to take suggestions! In the meantime, it's very clear we need to rework the trait solver. This resolves the extreme performance slowdown experienced in #60846 -- I plan to add a perf.rust-lang.org regression test to track this.

Caveat: I've not run `x.py test` in full yet.

r? @pnkfelix
cc @arielb1

Fixes #60846

Auto merge of #61739 - chansuke:separate-unit-tests, r=petrochenkov

Separate unit tests

I'm working on #61097.

About half of the modules are done but dozens of modules are still remaining. I will rebase and squash the commits later.

if if if if

Fix tidy

Separate libsyntax_ext module

Separate libfmt_macros module

Separate bootstrap module

Separate libtest module

Separate libserialize module

Separate librustcdoc module

Separate librustc module

Separate librustc_metadata module

Separate librustc_lint module

Separate librustc_data_structures module

Separate librustc_codegen_ssa module

Separate libgraphviz module

Separate libarena::lib module

Separate liballoc module

Auto merge of #60730 - matthewjasper:optimize-false-edges, r=pnkfelix

Optimize matches

Attempt to fix or improve #60571

This is breaking some diagnostics because the MIR for match arms isn't in source order any more.

cc @centril

Auto merge of #61886 - Centril:rollup-3p3m2fu, r=Centril

Rollup of 6 pull requests

Successful merges:

 - #61447 (Add some Vec <-> VecDeque documentation)
 - #61704 (Pass LLVM linker flags to librustc_llvm build)
 - #61829 (rustbuild: include llvm-libunwind in dist tarball)
 - #61832 (update miri)
 - #61866 (Remove redundant `clone()`s)
 - #61869 (Cleanup some new active feature gates)

Failed merges:

r? @ghost

Rollup merge of #61869 - Centril:cleanup-feature-gates, r=alexreg

Cleanup some new active feature gates

r? @alexreg

Rollup merge of #61866 - sinkuu:redundant_clone, r=petrochenkov

Remove redundant `clone()`s

Rollup merge of #61832 - RalfJung:miri, r=oli-obk

update miri

Fixes https://github.com/rust-lang/rust/issues/61830
Fixes https://github.com/rust-lang/rust/issues/61848

r? @oli-obk

Rollup merge of #61829 - Keruspe:libunwind-src, r=alexcrichton

rustbuild: include llvm-libunwind in dist tarball

Without this we cannot build with llvm-libunwind enabled from a release tarball.

Could it be backported in a beta rollup somehow so that this gets fixed before 1.36 is released?

Rollup merge of #61704 - petrhosek:llvm-linker-flags, r=alexcrichton

Pass LLVM linker flags to librustc_llvm build

Some -L and -l flags may be needed even when building librustc_llvm,
for example when using static libc++ on Linux we may need to manually
specify the library search path and -ldl -lpthread as additional link
dependencies. We pass LLVM linker flags from config to librustc_llvm
build to make sure these cases are handled.

Rollup merge of #61447 - scottmcm:vec-vecdeque, r=sfackler

Add some Vec <-> VecDeque documentation

These are more than just `.into_iter().collect()`, so talk about some of their nuances.

For VecDeque -> Vec I'm trying to intentionally not write a guarantee for people making their own `Vec`s, since the rules are more complicated than I think we want to commit to forever.

The "Vec -> VecDeque doesn't reallocate" guarantee seems reasonable, though.  (And I'm intentionally ambiguous about when it's O(1) instead of O(n).)

librustc_codegen_llvm: Use repr(transparent) for bitflags over repr(C) (#61306)

In order to make sure that Rust's bitflags types are passed the same
way in the Rust ABI as they are in the C ABI, we need to use the attribute
repr(transparent) over the repr(C) attribute for the single-field bitflags
structs in in order to prevent ABI mismatches. Thanks to Michael Karcher
for finding this bug.

Auto merge of #61828 - RalfJung:cfg-if, r=alexcrichton

make sure we use cfg-if as a std dependency

xargo currently fails to build libstd because this feature is missing. My guess is that it works in rustc because the feature is enabled elsewhere, but that does not help for a libstd-only build.

Miri is currently in a state where it is shipped but broken, which makes CI fail for projects that are tested in Miri. So this is kind of urgent.

Cc @alexcrichton  https://github.com/rust-lang/rust/pull/61720

Auto merge of #61868 - Centril:rollup-gglsecp, r=Centril

Rollup of 6 pull requests

Successful merges:

 - #61785 (note some safety concerns of raw-ptr-to-ref casts)
 - #61805 (typeck: Fix ICE for blocks in repeat expr count.)
 - #61813 (Remove some unnecessary symbol interner ops)
 - #61824 (in which we decline to lint single-use lifetimes in `derive`d impls)
 - #61844 (Change `...` to `..=` where applicable)
 - #61854 (Minor cosmetic improvements to accompany PR 61825)

Failed merges:

r? @ghost

cleanup some new active feature gates.

Rollup merge of #61854 - alexreg:fix-type-alias-enum-patterns, r=Centril

Minor cosmetic improvements to accompany PR 61825

r? @Centril

Rollup merge of #61844 - AaronKutch:master, r=Centril

Change `...` to `..=` where applicable

This is mainly to fix #61816, but I decided to manually check a few thousand `...` throughout the code base to check for any other cases. I think I found a documentation bug in `src\libsyntax\ast.rs` where both `1..` and `1...` where mentioned. If there is internal support for both `1..` and `1..=` (that can exist before error handling gets to it), then I can add that back.
There were some other cases that look like `// struct Closure<'l0...'li, T0...Tj, CK, CS, U0...Uk> {`, `// <P0 as Trait<P1...Pn>>::Foo: 'a`, and `assert!(min <= max, "discriminant range is {}...{}", min, max);`, but I am not sure if I should change those.
There are a bunch of cases in the `/test/` directory that could be changed, but I presume I should just leave those be.

Rollup merge of #61824 - rust-lang:single_derive, r=eddyb

in which we decline to lint single-use lifetimes in `derive`d impls

Resolves #53738.

r? @eddyb

Rollup merge of #61813 - matthewjasper:remove-unnecessary-symbol-ops, r=petrochenkov

Remove some unnecessary symbol interner ops

* Don't gensym symbols that don't need to worry about colliding with other symbols
* Use symbol constants instead of interning string literals in a few places.
* Don't generate a module in `__register_diagnostic`

r? @petrochenkov

Rollup merge of #61805 - davidtwco:ice-const-generic-repeat-expr-count-sequel, r=varkor

typeck: Fix ICE for blocks in repeat expr count.

Fixes #61336 (again). This PR fixes an ICE that occured when a block expression resolving to a const generic was used for the count of an array repeat expression.

r? @varkor

Rollup merge of #61785 - RalfJung:as-ref, r=rkruppe

note some safety concerns of raw-ptr-to-ref casts

Auto merge of #61143 - estebank:issue-61106, r=eddyb

When suggesting borrow, remove useless clones

Fix #61106.

Remove unnecessary `.clone()`

Use `slice::from_ref` instead of cloning

Auto merge of #59752 - Zoxc:dylib-fix, r=alexcrichton

Limit dylib symbols

This makes `windows-gnu` match the behavior of `windows-msvc`. It probably doesn't make sense to export these symbols on other platforms either.

Auto merge of #61825 - Centril:tauv-infer-fix, r=petrochenkov

type_alias_enum_variants: fix #61801; allow a path pattern to infer

Fix #61801.

Given a type-relative path pattern referring to an enum variant through a type alias, allow inferring the generic argument applied in the expectation set by the scrutinee of a `match` expression.

Similar issues may exist for `let` statements but I don't know how to test for that since `PhantomData<T>` is necessary...)

The gist of the problem here was that `resolve_ty_and_res_ufcs` was called twice which is apparently no good... It is possible that this PR is papering over some deeper problem, but that is beyond my knowledge of the compiler.

r? @petrochenkov
cc @eddyb @alexreg
cc https://github.com/rust-lang/rust/pull/61682
cc https://github.com/rust-lang/rust/issues/49683

Minor cosmetic improvements to accompany PR 61825

update miri

review comment: do not rely on path str to identify std::clone::Clone

Use `sym` constansts for `PrimitiveTypeTable` keys

Avoid some unnecessary symbol interner operations

review comments: avoid string modification

Change `...` to `..=` where applicable

Auto merge of #61817 - eddyb:begone-gcx-attempt-2, r=oli-obk

Unify all uses of 'gcx and 'tcx.

This is made possible by @Zoxc landing #57214 (see https://github.com/rust-lang/rust/pull/57214#issuecomment-465036053 for the decision).

A bit of context for the approach: just like #61722, this is *not* how I originally intended to go about this, but @Zoxc and my own experimentation independently resulted in the same conclusion:
The interim alias `type TyCx<'tcx> = TyCtxt<'tcx, 'tcx>;` attempt required more work (adding `use`s), even only for handling the `TyCtxt<'tcx, 'tcx>` case and not the general `TyCtxt<'gcx, 'tcx>` one.

What this PR is based on is the realization that `'gcx` is a special-enough name that it can be replaced, without caring for context, with `'tcx`, and then repetitions of the name `'tcx` be compacted away.
After that, only a small number of error categories remained, each category easily dealt with with either more mass replacements (e.g. `TyCtxt<'tcx, '_>` -> `TyCtxt<'tcx>`) or by hand.

For the `rustfmt` commit, I used https://github.com/rust-lang/rustfmt/issues/1324#issuecomment-482109952, and manually filtered out some noise, like in #61735 and #61722, and like the latter, there was also a weird bug to work around.
It should be reviewed separately, and dropped if unwanted (in this PR it's pretty significant).

cc @rust-lang/compiler r? @nikomatsakis

Run `rustfmt --file-lines ...` for changes from previous commits.

Unify all uses of 'gcx and 'tcx.

Auto merge of #61421 - vorner:string-in-rc-into-raw-docs, r=RalfJung

docs: Use String in Rc::into_raw examples

It is unclear if accessing an integer after `drop_in_place` has been
called on it is undefined behaviour or not, as demonstrated by the
discussion in
https://github.com/rust-lang/rust/pull/60766#pullrequestreview-243414222.

Avoid these uncertainties by using String which frees memory in its
`drop_in_place` to make sure this is undefined behaviour. The message in
the docs should be to watch out and not access the data after that, not
discussing when one maybe could get away with it O:-).

put back the workarounds for #60846

based on https://github.com/rust-lang/rust/pull/61754#issuecomment-501743750 I am adding `bootstrap` to the cfg-preconditions for the two manual `unsafe impls`'s of `Send` and `Sync` for `TokenTree`.

Auto merge of #61679 - zackmdavis:maybe_dont_indicate_the_anonymous_lifetime, r=oli-obk

in which we decline to suggest the anonymous lifetime in declarations

The elided-lifetimes-in-path lint (part of our suite of Rust 2018 idiom lints which we are hoping to promote to Warn status) was firing with an illegal suggestion to write an anonymous lifetime in a
struct/item declaration (where we don't allow it). The linting code was already deciding whether to act on the basis of a `ParamMode` enum, indicating whether the present path-segment was part of an
expression, or anywhere else. The present case seemed to be part of the "anywhere else", and yet meriting different rules as far as the lint was concerned, so it seemed expedient to introduce a new enum member. We yank out `TyKind::Path` arm into its own method so that we can call it with our new `ParamMode` specifically when lowering struct fields—one would have hoped to think of something more elegant than this, but it definitely beats changing the signature of `lower_ty` to take a `ParamMode`!

Resolves #61124.

cc @memoryruins
r? @oli-obk

rustbuild: include llvm-libunwind in dist tarball

Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>

make sure we use cfg-if as a std dependency

note some safety concerns of raw-ptr-to-ref casts

type_alias_enum_variants: add regression test for #61801.

in which we decline to lint single-use lifetimes in `derive`d impls

Resolves #53738.

in which we decline to suggest the anonymous lifetime in declarations

The elided-lifetimes-in-path lint (part of our suite of Rust 2018
idiom lints which we are hoping to promote to Warn status) was firing
with an illegal suggestion to write an anonymous lifetime in a
struct/item declaration (where we don't allow it). The linting code
was already deciding whether to act on the basis of a `ParamMode`
enum, indicating whether the present path-segment was part of an
expression, or anywhere else. The present case seemed to be part of
the "anywhere else", and yet meriting different rules as far as the
lint was concerned, so it seemed expedient to introduce a new enum
member. We yank out a `TyKind::Path` arm into its own method so that
we can call it with our new `ParamMode` specifically when lowering
struct fields. (The alternative strategy of changing the signature of
`lower_ty` to take a `ParamMode` would be inelegant given that most of
the `TyKind` match arm bodies therein don't concern themselves with
`ParamMode`.)

Resolves #61124.

PatKind::Path: avoid calling resolve_ty_and_res_ufcs twice.

Auto merge of #61803 - Centril:write_resolution, r=petrochenkov

typeck: small refactoring, add 'fn write_resolution'

Auto merge of #61792 - lzutao:issue-51301, r=Centril

Add ui test for issue 51301

Closes #51301

Verify that the clone method call actually corresponds to std::clone::Clone::clone

When suggesting to borrow, remove useless clones

typeck: Fix ICE for blocks in repeat expr count.

This commit extends the work in #61698 to get the `DefId` of const
parameters from block that resolve to a const parameter (as well as
const parameters directly, as it was previously).

Auto merge of #61639 - Mark-Simulacrum:bootstrap-cleanup, r=alexcrichton

Bootstrap cleanup

Each commit is (mostly) standalone and probably best reviewed as such. Nothing too major just some drive-by nits as I was looking through the code.

r? @alexcrichton

Add a test for simple matches

Add some more comments on how TestKind works

Generate MIR thats easier for llvm for str matches

LLVM appears to prefer (spend less time optimizing) long if chains if
it receives them in approzimately source order.
This fixes a ~10% regression for optimized builds of the encoding benchmark
on perf.rlo due to the changes to decision tree construction.

Call str::eq and <[T]>::eq for match comparisons

We used to call the less efficient `<&str>::eq` and `<&[T]>::eq`.

Create fewer basic blocks in match MIR lowering

Auto merge of #61772 - alexcrichton:pr-and-master-builds, r=pietroalbini

ci: Enable toolstate tracking on Azure

Currently just run it through its paces but don't actually push to
official locations. Instead let's just push to a separate fork (mine) as
well as open issues in a separate fork (mine). Make sure that people
aren't pinged for these issues as well!

This should hopefully ensure that everything is working on Azure and
give us a chance to work through any issues that come up.

Fixes https://github.com/rust-lang/rust/issues/61790
Fixes https://github.com/rust-lang/rust/issues/61371

Remove unnecessary Std dependency

Delete unused fields on Crate struct

Inline prepare_tool_cmd

Removing the tool argument in the previous commit means it's no longer
restricted to just bootstrap tools despite being written as such.
Inlining it prevents accidental use.

Delete unnecessary command

Delete Rustbook step

There's no need to have it given it merely forwarded to RustbookSrc.

typeck: small refactoring, add 'fn write_resolution'

ci: Enable toolstate tracking on Azure

Currently just run it through its paces but don't actually push to
official locations. Instead let's just push to a separate fork (mine) as
well as open issues in a separate fork (mine). Make sure that people
aren't pinged for these issues as well!

This should hopefully ensure that everything is working on Azure and
give us a chance to work through any issues that come up.

Auto merge of #61799 - Centril:rollup-vpm5uxr, r=Centril

Rollup of 5 pull requests

Successful merges:

 - #61598 (Handle index out of bound errors during const eval without panic)
 - #61720 (std: Remove internal definitions of `cfg_if!` macro)
 - #61757 (Deprecate ONCE_INIT in future 1.38 release)
 - #61766 (submodules: update clippy from c0dbd34b to bd33a97c)
 - #61791 (Small cleanup in `check_pat_path`)

Failed merges:

r? @ghost

Rollup merge of #61791 - Centril:cleanup-check_pat_path, r=petrochenkov

Small cleanup in `check_pat_path`

Rollup merge of #61766 - matthiaskrgr:submodule_upd, r=oli-obk

submodules: update clippy from c0dbd34b to bd33a97c

Changes:
````
Fix implicit_return docs
rustup https://github.com/rust-lang/rust/pull/61758/files
Remove wrong lifetime from LintContext
Workaround for rust-lang/rustfmt#3615
Fixing eta with respect to lazy evaluation.
````
r? @oli-obk

Rollup merge of #61757 - sfackler:deprecate-once-init, r=alexcrichton

Deprecate ONCE_INIT in future 1.38 release

Once::new() has been a stable const fn for a while now.

Closes #61746

Rollup merge of #61720 - alexcrichton:libstd-cfg-if-dep, r=sfackler

std: Remove internal definitions of `cfg_if!` macro

This is duplicated in a few locations throughout the sysroot to work
around issues with not exporting a macro in libstd but still wanting it
available to sysroot crates to define blocks. Nowadays though we can
simply depend on the `cfg-if` crate on crates.io, allowing us to use it
from there!

Rollup merge of #61598 - estebank:const-idx, r=oli-obk

Handle index out of bound errors during const eval without panic

Fix #61595

docs: Use String in Rc::into_raw examples

It is unclear if accessing an integer after `drop_in_place` has been
called on it is undefined behaviour or not, as demonstrated by the
discussion in
https://github.com/rust-lang/rust/pull/60766#pullrequestreview-243414222.

Avoid these uncertainties by using String which frees memory in its
`drop_in_place` to make sure this is undefined behaviour. The message in
the docs should be to watch out and not access the data after that, not
discussing when one maybe could get away with it O:-).

revert change incorrectly identified as "hack"

put back negative impls to ensure `Span` is not `Send` nor `Sync`

Auto merge of #61743 - RalfJung:miri, r=oli-obk

update miri

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

r? @oli-obk

update miri

submodules: update clippy from c0dbd34b to 7b2a7a22

Changes:
````
Fix wrong lifetime of TyCtxt
travis: Wait at most 30 minutes for base test
Typos and minor grammar corrections
Adds lint for integer division
redundant_closure_for_method_calls fixes: lint does not trigger when there is a difference in mutability lint does not trigger when the method belongs to a trait which is not implemebted directly (Deref)
Fix implicit_return docs
rustup https://github.com/rust-lang/rust/pull/61758/files
Remove wrong lifetime from LintContext
Workaround for rust-lang/rustfmt#3615
Fixing eta with respect to lazy evaluation.
````

Deprecate ONCE_INIT

Once::new() has been a stable const fn for a while now.

Closes #61746

Auto merge of #61597 - lnicola:bump-rand, r=alexcrichton

Bump dirs, rand and redox_users

Part of #57724.

Add ui test for issue 51301

Small cleanup in check_pat_path.

Auto merge of #61789 - Centril:rollup-hhyvopq, r=Centril

Rollup of 9 pull requests

Successful merges:

 - #60376 (Stabilize Option::xor)
 - #61398 (Stabilize copy_within)
 - #61629 (Hygienize macros in the standard library)
 - #61675 (Include frame pointer for bare metal RISC-V targets)
 - #61750 (Fix x.py install)
 - #61761 (Add an alias for x86_64-sun-solaris target tuple)
 - #61762 (rustbuild: fix libtest_stamp)
 - #61763 (ci: fix ci stats upload condition)
 - #61776 (Fix typos in error_codes)

Failed merges:

r? @ghost