Improve AddrParseError description - #96168
Conversation
|
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
|
r? @kennytm (rust-highfive has picked a reviewer for you, use r? to override) |
|
r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs (Changes observable runtime behaviour of library APIs— |
|
Name bikeshedding aside, this seems like a reasonable fix to me. |
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.
e0ff36f to
0255398
Compare
|
@bors r+ rollup |
|
📌 Commit 0255398 has been approved by |
…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.
…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.
Rollup of 6 pull requests Successful merges: - rust-lang#93313 (Check if call return type is visibly uninhabited when building MIR) - rust-lang#96160 (Miri/interpreter debugging tweaks) - rust-lang#96167 (Replace sys/unix/weak AtomicUsize with AtomicPtr) - rust-lang#96168 (Improve AddrParseError description) - rust-lang#96206 (Use sys::unix::locks::futex* on wasm+atomics.) - rust-lang#96234 (remove_dir_all_recursive: treat ELOOP the same as ENOTDIR) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…rror-description, r=dtolnay feat(num): improve error messages for `TryFromIntError` - Tracking issue: rust-lang#153978 This pull request improves the `Display` trait implementation for `TryFromIntError` by providing more specific error messages based on the underlying `IntErrorKind`. Currently, the error message is always `"out of range integral type conversion attempted"`. This makes debugging difficult because users cannot distinguish the detailed cause of the error from the error message. `IntErrorKind::Empty` and `IntErrorKind::InvalidDigit` should be unreachable. I don't think this is breaking changes, because similar changes were made in the past in rust-lang#96168. See also: <https://users.rust-lang.org/t/are-changes-to-fmt-display-considered-breaking/59775>
Rollup merge of #156225 - sorairolake:improve-try-from-int-error-description, r=dtolnay feat(num): improve error messages for `TryFromIntError` - Tracking issue: #153978 This pull request improves the `Display` trait implementation for `TryFromIntError` by providing more specific error messages based on the underlying `IntErrorKind`. Currently, the error message is always `"out of range integral type conversion attempted"`. This makes debugging difficult because users cannot distinguish the detailed cause of the error from the error message. `IntErrorKind::Empty` and `IntErrorKind::InvalidDigit` should be unreachable. I don't think this is breaking changes, because similar changes were made in the past in #96168. See also: <https://users.rust-lang.org/t/are-changes-to-fmt-display-considered-breaking/59775>
…ription, r=dtolnay feat(num): improve error messages for `TryFromIntError` - Tracking issue: rust-lang/rust#153978 This pull request improves the `Display` trait implementation for `TryFromIntError` by providing more specific error messages based on the underlying `IntErrorKind`. Currently, the error message is always `"out of range integral type conversion attempted"`. This makes debugging difficult because users cannot distinguish the detailed cause of the error from the error message. `IntErrorKind::Empty` and `IntErrorKind::InvalidDigit` should be unreachable. I don't think this is breaking changes, because similar changes were made in the past in rust-lang/rust#96168. See also: <https://users.rust-lang.org/t/are-changes-to-fmt-display-considered-breaking/59775>
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.