diff options
author | Joel Galenson <jgalenson@google.com> | 2021-10-12 16:13:16 +0000 |
---|---|---|
committer | Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com> | 2021-10-12 16:13:16 +0000 |
commit | 05871d5ee1dbc86c528260f0085d4ededae19607 (patch) | |
tree | e1f6fda29fc8eaa8881f7ce16ca2b542cd95dcb6 | |
parent | 8b0fc143c55dfc0e272051063fa2de05c5a71cd2 (diff) | |
parent | dd43a7c19d692146094b8646d40f2a5d7ba46afa (diff) | |
download | bstr-05871d5ee1dbc86c528260f0085d4ededae19607.tar.gz |
Merge "Upgrade rust/crates/bstr to 0.2.17" am: b37d5f93e4 am: e4ddd06e3e am: 0dfdf332b6 am: 27ca9d5733 am: dd43a7c19d
Original change: https://android-review.googlesource.com/c/platform/external/rust/crates/bstr/+/1832697
Change-Id: I352f79fa84f9ebdf9201e90da7ed1a9dae342f35
-rw-r--r-- | .cargo_vcs_info.json | 2 | ||||
-rw-r--r-- | Android.bp | 10 | ||||
-rw-r--r-- | Cargo.toml | 11 | ||||
-rw-r--r-- | Cargo.toml.orig | 2 | ||||
-rw-r--r-- | METADATA | 8 | ||||
-rw-r--r-- | README.md | 29 | ||||
-rw-r--r-- | 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" } } @@ -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 @@ -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 <jamslam@gmail.com>"] 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 <jamslam@gmail.com>"] description = "A string type that is not required to be valid UTF-8." documentation = "https://docs.rs/bstr" @@ -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 } } @@ -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 @@ -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 |