This commit extends the work in rust-lang#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).

…:Clone::clone

Resolves rust-lang#53738.

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.

When suggesting borrow, remove useless clones

Fix rust-lang#61106.

…tsakis

Updates smallvec and new_debug_unreachable

The version `0.6.10` of smallvec has released that fixes an [ICE](rust-lang#61549).
This is re-submission of rust-lang#58773.
And this may let rust-lang#56440 re-start.

…=oli-obk

prepare for Intptrcast model

rust-lang#61668 done right (I hope so). r? @RalfJung @oli-obk

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

…expr-count-sequel, r=varkor

typeck: Fix ICE for blocks in repeat expr count.

Fixes rust-lang#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

…mbol-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

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

Resolves rust-lang#53738.

r? @eddyb

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

Fix rust-lang#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 rust-lang#61682
cc rust-lang#49683

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

This is mainly to fix rust-lang#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.