Rollup of 6 pull requests #102636
Closed
Rollup of 6 pull requests #102636
Conversation
This file contains 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
This rule became irrelevant since c58246e made it so that the `summary::before` pseudo-element contains an SVG instead of text.
…joshtriplett add methods to TCP and UDP sockets to modify hop limit * adds methods to set value of IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS on ipv6 sockets * I added some noop methods for different systems to keep things consistent. Maybe someone could please clarify if these noop funcs are needed? and, if so, why? Just for my own learning. This is my first addition of a new feature so let me know if I missed something in the process. I read the rustc dev guide about implementing new features but since the change here is simple, it suggested that a PR would be enough. Fixes rust-lang#47727
…riplett Implement `Ready::into_inner()` Tracking issue: rust-lang#101196. This implements a method to unwrap the value inside a `Ready` outside an async context. See https://docs.rs/futures/0.3.24/futures/future/struct.Ready.html#method.into_inner for previous work. This was discussed in [Zulip beforehand](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/.60Ready.3A.3Ainto_inner.28.29.60): > An example I'm hitting right now: I have a cross-platform library that provides a functions that returns a `Future`. The only reason why it returns a `Future` is because the WASM platform requires it, but the native doesn't, to make a cross-platform API that is equal for all I just return a `Ready` on the native targets. > > Now I would like to expose native-only functions that aren't async, that users can use to avoid having to deal with async when they are targeting native. With `into_inner` that's easily solvable now. > > I want to point out that some internal restructuring could be used to solve that problem too, but in this case it's not that simple, the library uses internal traits that return the `Future` already and playing around with that would introduce unnecessary `cfg` in a lot more places. So it is really only a quality-of-life feature.
…gs, r=Mark-Simulacrum Adding target_rustcflags to `compiletest` TargetCfg creation Adjustment to rust-lang#102134, ensures config returned by `rustc --target foo --print cfg` accurately reflects rustflags passed via `target_rustcflags`. Fixes breaking change of not correctly handling `x.py test ... --test-args "--target-rustcflags -Cpanic=abort --target-rustcflags -Zpanic_abort_tests"` cc `@djkoloski`
…vidtwco Delay evaluating lint primary message until after it would be suppressed Fixes rust-lang#102561 Fixes rust-lang#102572
…, r=GuillaumeGomez rustdoc: remove font family CSS on `.rustdoc-toggle summary::before` This rule became irrelevant since c58246e made it so that the `summary::before` pseudo-element contains an SVG instead of text.
Change the parameter name of From::from to `value`
The `From` trait is currently defined as:
```rust
pub trait From<T>: Sized {
fn from(_: T) -> Self;
}
```
The name of the argument is `_`. I am proposing to change it to `value`, ie.
```rust
pub trait From<T>: Sized {
fn from(value: T) -> Self;
}
```
This would be more consistent with the `TryFrom`, which looks like this:
```rust
pub trait TryFrom<T>: Sized {
type Error;
fn try_from(value: T) -> Result<Self, Self::Error>;
}
```
The reason for this proposal is twofold:
1. Consistency with the rest of the standard library. The `TryFrom` trait uses `value`, and no `From` implementation uses the default name (as it is quite useless).
2. When generating trait implementations with rust-analyzer/IntelliJ, the parameter name is copied, and it always has to be changed.
Optionally, another name like `x` could be used. I only propose `value` for consistency with `TryFrom`.
Changing parameter names is not a breaking change.
Note: this was originally posted as an internals thread [here](https://internals.rust-lang.org/t/change-the-argument-name-of-from-from/17480)
rustbot
added
T-compiler
|
@bors r+ rollup=never p=6 |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit 1247b74 with merge 23424f1f53f7d27e55396eeb6c37bf6c96c35493... |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
The job Click to see the possible cause of the failure (guessed by this bot) |
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:
Ready::into_inner()#101189 (ImplementReady::into_inner())compiletestTargetCfg creation #102438 (Adding target_rustcflags tocompiletestTargetCfg creation).rustdoc-toggle summary::before#102624 (rustdoc: remove font family CSS on.rustdoc-toggle summary::before)value#102628 (Change the parameter name of From::from tovalue)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup