…nstant functions

There's a few spots where semicolons are checked for to do error recovery,
and should not be suggested (or checked for other stuff).

Fixes rust-lang#87647

Notably, the passes at the end of `make_shim` aren't applied to them.

Also add a test case for inserting a semicolon on extern fns.

Without this fix, we got an error like this:

    error: expected one of `->`, `where`, or `{`, found `}`
     --> chk.rs:3:1
      |
    2 |   fn foo()
      |      ---  - expected one of `->`, `where`, or `{`
      |      |
      |      while parsing this `fn`
    3 | }
      | ^ unexpected token

Since this is inside an extern block, you're required to write function
prototypes with no body. This fixes a regression, and adds a test case
for it.

This one is a heavy `'tcx` user.

Two interesting ones:

This one had the `'tcx` declared on the function, despite the trait taking a `'tcx`:
```diff
-impl Visitor<'_> for UsedLocals {
+impl<'tcx> Visitor<'tcx> for UsedLocals {
     fn visit_statement(&mut self, statement: &Statement<'tcx>, location: Location) {
```

This one use in-band for one, and underscore for the other:
```diff
-pub fn remove_dead_blocks(tcx: TyCtxt<'tcx>, body: &mut Body<'_>) {
+pub fn remove_dead_blocks<'tcx>(tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) {
```

…e_name, r=Mark-Simulacrum

Deprecate crate_type and crate_name nested inside #![cfg_attr]

This implements the proposal in rust-lang#83676 (comment), with a future compatibility lint imposed on usage of crate_type/crate_name inside cfg's.

This is a compromise between removing `#![crate_type]` and `#![crate_name]` completely and keeping them as a whole, which requires somewhat of a hack in rustc and is impossible to support by gcc-rust. By only removing `#![crate_type]` and `#![crate_name]` nested inside `#![cfg_attr]` it becomes possible to parse them before a big chunk of the compiler has started.

Replaces rust-lang#83676

```rust
#![crate_type = "lib"] // remains working
#![cfg_attr(foo, crate_type = "bin")] // will stop working
```

# Rationale

As it currently is it is possible to try to access the stable crate id before it is actually set, which will panic. The fact that the Session contains mutable state beyond debugging things also doesn't completely sit well with me. Especially once parallel rustc becomes the default.

I think there is currently also a cyclic dependency where you need to set the stable crate id to be able to load crates, but you need to load crates to expand proc macro attributes that may define #![crate_name] or #![crate_type]. Currently crate level proc macro attributes are unstable or completely unsupported (can't remember which), so this is not a problem, but it may become an issue in the future.

Finally if we want to add incremental compilation to macro expansion or even parsing, we need the StableCrateId to be created together with the Session or even earlier as incremental compilation determines the incremental compilation session dir based on the StableCrateId.

Update certificates in some Ubuntu 16 images.

These images use crosstool-ng, which needs to download various things off the internet. The certificate for `www.kernel.org` no longer works with the ca-certificates in Ubuntu 16. This resolves the issue by grabbing from a newer image a certificate bundle from https://curl.se/ca/cacert.pem, which is usually somewhat up to date.

…, r=wesleywiser

Print a suggestion when comparing references to primitive types in `const fn`

Fixes rust-lang#90870.

…Mark-Simulacrum

Emphasise that an OsStr[ing] is not necessarily a platform string

Fixes rust-lang#53261

Since that issue was filed, rust-lang#56141 added a further clarification to the `OsString` docs. However the ffi docs may still leave the impression that an `OsStr` is in the platform native form. This PR aims to further emphasise that an `OsStr` is not necessarily a platform string.

…ected-semicolon, r=estebank

Do not add `;` to expected tokens list when it's wrong

There's a few spots where semicolons are checked for to do error recovery, and should not be suggested (or checked for other stuff).

Fixes rust-lang#87647

…anup, r=oli-obk

Address some FIXMEs left over from rust-lang#91475

This shouldn't change behavior, only clarify what we're currently doing. I filed rust-lang#91576 to see if the treatment of generator drop shims is intentional.

cc rust-lang#91475

…rochenkov

Remove `in_band_lifetimes` from `rustc_mir_transform`

Like rust-lang#91580, this was inspired by the conversation in rust-lang#44524 about possibly removing the feature from the compiler.  This crate is a heavy `'tcx` user, so is a nice case study.

r? ``@petrochenkov``

Three interesting ones:

This one had the `'tcx` declared on the function, despite the trait taking a `'tcx`:
```diff
-impl Visitor<'_> for UsedLocals {
+impl<'tcx> Visitor<'tcx> for UsedLocals {
     fn visit_statement(&mut self, statement: &Statement<'tcx>, location: Location) {
```

This one use in-band for one, and underscore for the other:
```diff
-pub fn remove_dead_blocks(tcx: TyCtxt<'tcx>, body: &mut Body<'_>) {
+pub fn remove_dead_blocks<'tcx>(tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) {
```

A spurious name, since there's no single-use-lifetime warning:
```diff
-pub fn run_passes(tcx: TyCtxt<'tcx>, body: &'mir mut Body<'tcx>, passes: &[&dyn MirPass<'tcx>]) {
+pub fn run_passes<'tcx>(tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>, passes: &[&dyn MirPass<'tcx>]) {
```