From 6b1d001e88756d0f1bd811afbdfbffc1a98ccb79 Mon Sep 17 00:00:00 2001 From: Joel Galenson Date: Wed, 22 Sep 2021 10:51:18 -0700 Subject: Upgrade rust/crates/bstr to 0.2.17 Test: make Change-Id: I677f67ad13e1cac6cecc89c8c78cebd0345c649a --- .cargo_vcs_info.json | 2 +- Android.bp | 10 +++------- Cargo.toml | 11 +++++------ Cargo.toml.orig | 2 +- METADATA | 8 ++++---- README.md | 29 +++++++++++++---------------- src/lib.rs | 23 ++++++++++++----------- 7 files changed, 39 insertions(+), 46 deletions(-) diff --git a/.cargo_vcs_info.json b/.cargo_vcs_info.json index 1a21384..ef4fb69 100644 --- a/.cargo_vcs_info.json +++ b/.cargo_vcs_info.json @@ -1,5 +1,5 @@ { "git": { - "sha1": "fffcb0ff62d8bebadefebbcbf20ae4460fa7a461" + "sha1": "e38e7a7ca986f9499b30202f49d79e531d14d192" } } diff --git a/Android.bp b/Android.bp index fc5547b..f073254 100644 --- a/Android.bp +++ b/Android.bp @@ -1,4 +1,4 @@ -// This file is generated by cargo2android.py --run --device --dependencies. +// This file is generated by cargo2android.py --run --device. // Do not modify this file as changes will be overridden on upgrade. package { @@ -43,6 +43,8 @@ rust_library { name: "libbstr", host_supported: true, crate_name: "bstr", + cargo_env_compat: true, + cargo_pkg_version: "0.2.17", srcs: ["src/lib.rs"], edition: "2018", features: [ @@ -58,9 +60,3 @@ rust_library { "libregex_automata", ], } - -// dependent_library ["feature_list"] -// byteorder-1.4.3 -// lazy_static-1.4.0 -// memchr-2.4.0 "std" -// regex-automata-0.1.9 diff --git a/Cargo.toml b/Cargo.toml index 453a24f..0f206ba 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -3,17 +3,16 @@ # When uploading crates to the registry Cargo will automatically # "normalize" Cargo.toml files for maximal compatibility # with all versions of Cargo and also rewrite `path` dependencies -# to registry (e.g., crates.io) dependencies +# to registry (e.g., crates.io) dependencies. # -# If you believe there's an error in this file please file an -# issue against the rust-lang/cargo repository. If you're -# editing this file be aware that the upstream Cargo.toml -# will likely look very different (and much more reasonable) +# If you are reading this file be aware that the original Cargo.toml +# will likely look very different (and much more reasonable). +# See Cargo.toml.orig for the original contents. [package] edition = "2018" name = "bstr" -version = "0.2.16" +version = "0.2.17" authors = ["Andrew Gallant "] exclude = ["/.github"] description = "A string type that is not required to be valid UTF-8." diff --git a/Cargo.toml.orig b/Cargo.toml.orig index 538f650..cbb6283 100644 --- a/Cargo.toml.orig +++ b/Cargo.toml.orig @@ -1,6 +1,6 @@ [package] name = "bstr" -version = "0.2.16" #:version +version = "0.2.17" #:version authors = ["Andrew Gallant "] description = "A string type that is not required to be valid UTF-8." documentation = "https://docs.rs/bstr" diff --git a/METADATA b/METADATA index b9fddec..bfc1d19 100644 --- a/METADATA +++ b/METADATA @@ -7,13 +7,13 @@ third_party { } url { type: ARCHIVE - value: "https://static.crates.io/crates/bstr/bstr-0.2.16.crate" + value: "https://static.crates.io/crates/bstr/bstr-0.2.17.crate" } - version: "0.2.16" + version: "0.2.17" license_type: NOTICE last_upgrade_date { year: 2021 - month: 5 - day: 19 + month: 9 + day: 22 } } diff --git a/README.md b/README.md index fd921aa..13bf0fc 100644 --- a/README.md +++ b/README.md @@ -171,12 +171,12 @@ My hope is to move to `1.0` within the next year and commit to its API so that `bstr` can be used as a public dependency. A large part of the API surface area was taken from the standard library, so -from an API design perspective, a good portion of this crate should be mature. -The main differences from the standard library are in how the various substring -search routines work. The standard library provides generic infrastructure for -supporting different types of searches with a single method, where as this -library prefers to define new methods for each type of search and drop the -generic infrastructure. +from an API design perspective, a good portion of this crate should be on solid +ground already. The main differences from the standard library are in how the +various substring search routines work. The standard library provides generic +infrastructure for supporting different types of searches with a single method, +where as this library prefers to define new methods for each type of search and +drop the generic infrastructure. Some _probable_ future considerations for APIs include, but are not limited to: @@ -195,10 +195,10 @@ Here are some examples that are _probably_ out of scope for this crate: The exact scope isn't quite clear, but I expect we can iterate on it. -In general, as stated below, this crate is an experiment in bringing lots of -related APIs together into a single crate while simultaneously attempting to -keep the total number of dependencies low. Indeed, every dependency of `bstr`, -except for `memchr`, is optional. +In general, as stated below, this crate brings lots of related APIs together +into a single crate while simultaneously attempting to keep the total number of +dependencies low. Indeed, every dependency of `bstr`, except for `memchr`, is +optional. ### High level motivation @@ -229,13 +229,10 @@ Consider, for example, trimming and splitting, along with their different variants. In other words, `bstr` is partially a way of pushing back against the -micro-crate ecosystem that appears to be evolving. It's not clear to me whether -this experiment will be successful or not, but it is definitely a goal of +micro-crate ecosystem that appears to be evolving. Namely, it is a goal of `bstr` to keep its dependency list lightweight. For example, `serde` is an -optional dependency because there is no feasible alternative, but `twoway` is -not, where we instead prefer to implement our own substring search. In service -of this philosophy, currently, the only required dependency of `bstr` is -`memchr`. +optional dependency because there is no feasible alternative. In service of +this philosophy, currently, the only required dependency of `bstr` is `memchr`. ### License diff --git a/src/lib.rs b/src/lib.rs index 700c14a..41142c9 100644 --- a/src/lib.rs +++ b/src/lib.rs @@ -1,5 +1,5 @@ /*! -An experimental byte string library. +A byte string library. Byte strings are just like standard Unicode strings with one very important difference: byte strings are only *conventionally* UTF-8 while Rust's standard @@ -98,10 +98,10 @@ method converts any `&[u8]` to a `&BStr`. # When should I use byte strings? -This library is somewhat of an experiment that reflects my hypothesis that -UTF-8 by convention is a better trade off in some circumstances than guaranteed -UTF-8. It's possible, perhaps even likely, that this is a niche concern for -folks working closely with core text primitives. +This library reflects my hypothesis that UTF-8 by convention is a better trade +off in some circumstances than guaranteed UTF-8. It's possible, perhaps even +likely, that this is a niche concern for folks working closely with core text +primitives. The first time this idea hit me was in the implementation of Rust's regex engine. In particular, very little of the internal implementation cares at all @@ -134,15 +134,16 @@ incremental way by only parsing chunks at a time, but this is often complex to do or impractical. For example, many regex engines only accept one contiguous sequence of bytes at a time with no way to perform incremental matching. -In summary, the conventional UTF-8 byte strings provided by this library is an -experiment. They are definitely useful in some limited circumstances, but how -useful they are more broadly isn't clear yet. +In summary, conventional UTF-8 byte strings provided by this library are +definitely useful in some limited circumstances, but how useful they are more +broadly isn't clear yet. # `bstr` in public APIs -Since this library is still experimental, you should not use it in the public -API of your crates until it hits `1.0` (unless you're OK with with tracking -breaking releases of `bstr`). +Since this library is not yet `1.0`, you should not use it in the public API of +your crates until it hits `1.0` (unless you're OK with with tracking breaking +releases of `bstr`). It is expected that `bstr 1.0` will be released before +2022. In general, it should be possible to avoid putting anything in this crate into your public APIs. Namely, you should never need to use the `ByteSlice` or -- cgit v1.2.3