`--extern-location` was an experiment to investigate the best way to
generate useful diagnostics for unused dependency warnings by enabling a
build system to identify the corresponding build config.

While I did successfully use this, I've since been convinced the
alternative `--json unused-externs` mechanism is the way to go, and
there's no point in having two mechanisms with basically the same
functionality.

This effectively reverts rust-lang#72603

The `vec!` macro has 3 rules, but two are not usable under
`no_global_oom_handling` builds of the standard library
(even with a zero size):

```rust
let _ = vec![42];    // Error: requires `exchange_malloc` lang_item.
let _ = vec![42; 0]; // Error: cannot find function `from_elem`.
```

Thus those two rules should not be available to begin with.

The remaining one, with an empty matcher, is just a shorthand for
`new()` and may not make as much sense to have alone, since the
idea behind `vec!` is to enable `Vec`s to be defined with the same
syntax as array expressions. Furthermore, the documentation can be
confusing since it shows the other rules.

Thus perhaps it is better and simpler to disable `vec!` entirely
under `no_global_oom_handling` environments, and let users call
`new()` instead:

```rust
let _: Vec<i32> = vec![];
let _: Vec<i32> = Vec::new();
```

Notwithstanding this, a `try_vec!` macro would be useful, such as
the one introduced in rust-lang#95051.

If the shorthand for `new()` is deemed worth keeping on its own,
then it may be interesting to have a separate `vec!` macro with
a single rule and different, simpler documentation.

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

…in a foreign crate

Adding diagnostic data on generators to the crate metadata and using it to provide
a better diagnostic on failure to meet send bound on futures originated from a foreign crate

`CRATE_DEF_ID` and `CrateNum::as_def_id` are almost always what we want.

Define a `NotHandle` type, that implements `std::error::Error`, and use
it as the error type in `HandleOrNull` and `HandleOrInvalid`.

Also, make the display messages more specific, and remove the `Copy`
implementation.

This test's expected stderr now includes a count of the number of types
that implment `Error`. This PR introduces two new types, so increment
the number by two.

The existing description was incorrect for socket addresses, and
misleading: users would see “invalid IP address syntax” and suppose they
were supposed to provide an IP address rather than a socket address.

I contemplated making it two variants (IP, socket), but realised we can
do still better for the IPv4 and IPv6 types, so here it is as six.

I contemplated more precise error descriptions (e.g. “invalid IPv6
socket address syntax: expected a decimal scope ID after %”), but that’s
a more invasive change, and probably not worthwhile anyway.

…c_fn_in_foreign_crate_diag_2, r=davidtwco

Improved diagnostic on failure to meet send bound on future in a foreign crate

Provide a better diagnostic on failure to meet send bound on futures in a foreign crate.

fixes rust-lang#78543

…dtwco

Remove `--extern-location` and all associated code

`--extern-location` was an experiment to investigate the best way to
generate useful diagnostics for unused dependency warnings by enabling a
build system to identify the corresponding build config.

While I did successfully use this, I've since been convinced the
alternative `--json unused-externs` mechanism is the way to go, and
there's no point in having two mechanisms with basically the same
functionality.

This effectively reverts rust-lang#72603

…, r=Mark-Simulacrum

`alloc`: make `vec!` unavailable under `no_global_oom_handling`

`alloc`: make `vec!` unavailable under `no_global_oom_handling`

The `vec!` macro has 3 rules, but two are not usable under
`no_global_oom_handling` builds of the standard library
(even with a zero size):

```rust
let _ = vec![42];    // Error: requires `exchange_malloc` lang_item.
let _ = vec![42; 0]; // Error: cannot find function `from_elem`.
```

Thus those two rules should not be available to begin with.

The remaining one, with an empty matcher, is just a shorthand for
`new()` and may not make as much sense to have alone, since the
idea behind `vec!` is to enable `Vec`s to be defined with the same
syntax as array expressions. Furthermore, the documentation can be
confusing since it shows the other rules.

Thus perhaps it is better and simpler to disable `vec!` entirely
under `no_global_oom_handling` environments, and let users call
`new()` instead:

```rust
let _: Vec<i32> = vec![];
let _: Vec<i32> = Vec::new();
```

Notwithstanding this, a `try_vec!` macro would be useful, such as
the one introduced in rust-lang#95051.

If the shorthand for `new()` is deemed worth keeping on its own,
then it may be interesting to have a separate `vec!` macro with
a single rule and different, simpler documentation.

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

…ochenkov

Stop using CRATE_DEF_INDEX outside of metadata encoding.

`CRATE_DEF_ID` and `CrateNum::as_def_id` are almost always what we want.  We should not manipulate raw `DefIndex` outside of metadata encoding.

…tion-improvements, r=joshtriplett

Improve AddrParseError description

The existing description was incorrect for socket addresses, and misleading: users would see “invalid IP address syntax” and suppose they were supposed to provide an IP address rather than a socket address.

I contemplated making it two variants (IP, socket), but realised we can do still better for the IPv4 and IPv6 types, so here it is as six.

I contemplated more precise error descriptions (e.g. “invalid IPv6 socket address syntax: expected a decimal scope ID after %”), but that’s a more invasive change, and probably not worthwhile anyway.

…rror-type, r=joshtriplett

 Define a dedicated error type for `HandleOrNull` and `HandleOrInvalid`.

Define `NullHandleError` and `InvalidHandleError` types, that implement std::error::Error, and use them as the error types in `HandleOrNull` and `HandleOrInvalid`,

This addresses [this concern](rust-lang#87074 (comment)).

This is the same as rust-lang#95387.

r? ``@joshtriplett``