Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 6 pull requests #96202

Closed
wants to merge 18 commits into from
Closed

Conversation

Dylan-DPC
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

jsgf and others added 18 commits April 15, 2022 11:19
`--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 <[email protected]>
…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 <[email protected]>
…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`
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Apr 19, 2022
@klensy
Copy link
Contributor

klensy commented Apr 19, 2022

duplicate #96203

@Dylan-DPC Dylan-DPC closed this Apr 19, 2022
@Dylan-DPC Dylan-DPC deleted the rollup-biwl0rw branch April 19, 2022 05:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants