Merge "Upgrade rust/crates/bstr to 0.2.17"android-s-v2-preview-2android-s-v2-preview-1android-s-v2-beta-2android-s-v2-preview-1

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 <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"
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