Rollup of 6 pull requests #96202
Closed
Rollup of 6 pull requests #96202
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
`--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
added
T-compiler
|
duplicate #96203 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
--extern-locationand all associated code #96086 (Remove--extern-locationand all associated code)alloc: makevec!unavailable underno_global_oom_handling#96089 (alloc: makevec!unavailable underno_global_oom_handling)HandleOrNullandHandleOrInvalid. #96195 ( Define a dedicated error type forHandleOrNullandHandleOrInvalid.)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup