rollup and start preparing for a 1.0 release #104
Merged
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
BurntSushi
force-pushed
the
ag/work
branch
4 times, most recently
from
51405a9
to
1f77e5c
Compare
I chose this because it's what appears to be the version of Rust that is in the current version of Debian stable (which is bullseye). I don't necessarily plan to always track Debian stable, but in the absence of any other constraint (like a strong desire to use something stabilized in a more recent Rust release), it seems like a fine place to sit.
I'm also trying to fix CI, which appears broken on macOS. The build fails with zero logs, so that means it's time to just start changing things until it works.
Allowing access to the buffer itself may make some use cases simpler when access to the original buffer after consuming a few lines is preferrable. Without it, one would have to find a way to count the consumed bytes themselves. Closes #101
This re-generates all of the Unicode DFAs with Unicode 14. Doing this update was a major pain: 1) Update ucd-generate to Unicode 14, cut release 2) Update regex-syntax to Unicode 14, cut release 3) Update ucd-generate to new regex-syntax, cut release 4) Update bstr by re-running Unicode generation shell script *phew*
This is a more specific name given that we know we're dealing with a '&[u8]'.
This implements 'ByteSlice::repeatn' with '<[u8]>::repeat'. 'repeat' on slices is stable since Rust 1.40.0 and does an exponential 'ptr::copy_nonoverlapping'. The implementation in 'alloc' also correctly handles the capacity overflow when 'len * n' is more than 'usize::MAX'. Closes #91
Previously, they would just return 'Vec<u8>' as the error type. But a 'FromUtf8Error' gives strictly more information, so we return that instead. Closes #52
This commit enables bstr to build and test without a dependency on std. This change was mostly munging 'use' statements to prefer 'core' and 'alloc' and changing around some conditional compilation. This change also enables bstr` to successfully test in 'no_std' and 'alloc' configurations. This includes doc tests. Previously, neither the library nor doc tests worked right if 'std' was disabled. Fixes #79, Closes #83
In a few places I must have got lazy when defining the iterator types and forced haystacks and needles/splitters to always have the same lifetime. This works in most cases, but #45 shows a case where it breaks down. To fix it, we just make sure we represent all of our lifetimes in our types. Note that #45 was reported against our split types, but we also have this issue with our find types too. Indeed, our split types are built on top of our find types, so we just fix everything. This is a breaking change since we are adding a new lifetime parameter to several public API types. Fixes #45
Our pattern has been to group forward/reverse APIs together, but the split_once APIs were put between 'split_str' and 'rsplit_str'. So we move them both below 'rsplit_str'.
It currently uses 'char::is_whitespace', but this is more of an implementation detail. While 'char::is_whitespace' is available in 'core', it's plausible that we might use our own data some data. In particular, 'trim' already uses its own data. I believe this is the only routine that makes direct use of some kind of Unicode data that wasn't previously gated behind the 'unicode' feature. Ref #40
This switches over to using as fewer 'use' statements. We don't go with the minimal number though, since I still find it useful to split 'use' statements into logical blocks: core, alloc, std, third party, crate.
It's nice to reserve 'pub' strictly for things that are part of the public API, as a way of making it easy to see which things are and aren't part of the API. I'm sure there are more 'pub' things that we should make 'pub(crate)', but this one stood out to me.
This was referenced Jul 6, 2022
Closed
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.
Ref #40