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 several outstanding PRs + bump MSRV to Rust 1.73 #198

Merged
merged 25 commits into from
Nov 13, 2024

Conversation

BurntSushi
Copy link
Owner

@BurntSushi BurntSushi commented Nov 13, 2024

This is a rollup of a few outstanding PRs.

I'll do a minor version bump, so I'll take advantage of that opportunity and bump the MSRV to Rust 1.73.

Closes #160, Closes #189, Closes #191, Closes #192, Closes #197

lopopolo and others added 25 commits November 13, 2024 17:08
This is a pedantic lint, but it removes a transmute where a cast will do.
The code is safe for the same reasons the transmute is safe: `BStr` is a repr
transparent wrapper around `[u8]`.
Make all of the debug output in lower-case.

Closes #188, Closes #189
Add instances for `[u8; N]` and `&[u8; N]`, for convenience.

Closes #191
A build on nightly currently produces this:

warning: elided lifetime has a name
  --> src/escape_bytes.rs:15:43
   |
14 | impl<'a> EscapeBytes<'a> {
   |      -- lifetime `'a` declared here
15 |     pub(crate) fn new(bytes: &'a [u8]) -> EscapeBytes {
   |                                           ^^^^^^^^^^^ this elided lifetime gets resolved as `'a`
   |
   = note: `#[warn(elided_named_lifetimes)]` on by default

Fix that by changing `EscapeBytes` to `Self`, which constrains the
lifetime.

Closes #192
This isn't strictly necessary, but I'm doing a minor version bump and
might as well move the trains along.
@BurntSushi BurntSushi changed the title rollup of several outstanding PRs rollup of several outstanding PRs + bump MSRV to Rust 1.73 Nov 13, 2024
@BurntSushi BurntSushi merged commit f679928 into master Nov 13, 2024
8 checks passed
@BurntSushi BurntSushi deleted the ag/rollup branch November 13, 2024 22:25
@BurntSushi
Copy link
Owner Author

This PR is on crates.io in bstr 1.11.0.

@grodin grodin mentioned this pull request Jan 14, 2025
@lopopolo
Copy link
Contributor

lopopolo commented Feb 1, 2025

@BurntSushi #189 I think is a breaking change. The change in casing of BStr's debug format ended up breaking some tests of mine.

Given one of the documented uses of BStr is to provide human readable debug output, I thought that meant the debug format would be stable (modulo bug fixes). Curious what you think here.

lopopolo added a commit to artichoke/artichoke that referenced this pull request Feb 1, 2025
`bstr` 1.11.x updated the debug format of `BStr` to be all lowercase.

See:

- BurntSushi/bstr#189
- BurntSushi/bstr#198 (comment)
@BurntSushi
Copy link
Owner Author

I think it's a pretty strong convention that the output of Debug impls isn't meant to be stable. We've never considered it as such in std anyway. I don't know if that policy is written down anywhere though. But I think it's just generally impractical to consider Debug output to be stable. Consider that derive(Debug) will by default leak the internal details of a type. So if you add or remove or change an internal field of a type, that in turn will change the Debug output on a derive(Debug) for example.

I do agree that the Debug impl for BStr is one of the stars of the show here, but there really isn't any explicit guarantee of what it will be emitted. The only documented guarantee is that invalid bytes are emitted as hex escapes.

And the fix here is making the output more consistent. I certainly meant for the case of the hex escapes to all be the same. But it wasn't.

@lopopolo
Copy link
Contributor

lopopolo commented Feb 1, 2025

cool, thanks for the detailed explanation! I'll update my tests 🫡

lopopolo added a commit to artichoke/artichoke that referenced this pull request Feb 3, 2025
`bstr` 1.11.x updated the debug format of `BStr` to be all lowercase.

See:

- BurntSushi/bstr#189
- BurntSushi/bstr#198 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants