chore: fix clippy lints

src/search/aggregations/bucket/date_histogram_aggregation.rs

@@ -123,14 +123,14 @@ impl DateHistogramAggregation {
     /// Order field allows changing this behavior.
     ///
     /// > Sorting by ascending `_count` or by sub aggregation is discouraged as it increases the
-    /// [error](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-terms-aggregation.html#search-aggregations-bucket-terms-aggregation-approximate-counts)
-    /// on document counts. It is fine when a single shard is queried, or when the field that is
-    /// being aggregated was used as a routing key at index time: in these cases results will be
-    /// accurate since shards have disjoint values. However otherwise, errors are unbounded.
-    /// One particular case that could still be useful is sorting by
-    /// [min](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-min-aggregation.html) or
-    /// [max](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-max-aggregation.html)
-    /// aggregation: counts will not be accurate but at least the top buckets will be correctly picked.
+    /// > [error](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-terms-aggregation.html#search-aggregations-bucket-terms-aggregation-approximate-counts)
+    /// > on document counts. It is fine when a single shard is queried, or when the field that is
+    /// > being aggregated was used as a routing key at index time: in these cases results will be
+    /// > accurate since shards have disjoint values. However otherwise, errors are unbounded.
+    /// > One particular case that could still be useful is sorting by
+    /// > [min](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-min-aggregation.html) or
+    /// > [max](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-max-aggregation.html)
+    /// > aggregation: counts will not be accurate but at least the top buckets will be correctly picked.
     pub fn order<T>(mut self, order: T) -> Self
     where
         T: Into<TermsOrderCollection>,

src/search/aggregations/bucket/mod.rs

@@ -13,9 +13,9 @@
 //! and others dynamically create the buckets during the aggregation process.
 //!
 //! > The maximum number of buckets allowed in a single response is limited by
-//! a dynamic cluster setting named
-//! [`search.max_buckets`](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-settings.html#search-settings-max-buckets).
-//! It defaults to `65,535`. Requests that try to return more than the limit will fail with an exception.
+//! > a dynamic cluster setting named
+//! > [`search.max_buckets`](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-settings.html#search-settings-max-buckets).
+//! > It defaults to `65,535`. Requests that try to return more than the limit will fail with an exception.
 //!
 //! <https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket.html>
 

src/search/aggregations/bucket/terms_aggregation.rs

@@ -89,14 +89,14 @@ impl TermsAggregation {
     /// Order field allows changing this behavior.
     ///
     /// > Sorting by ascending `_count` or by sub aggregation is discouraged as it increases the
-    /// [error](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-terms-aggregation.html#search-aggregations-bucket-terms-aggregation-approximate-counts)
-    /// on document counts. It is fine when a single shard is queried, or when the field that is
-    /// being aggregated was used as a routing key at index time: in these cases results will be
-    /// accurate since shards have disjoint values. However otherwise, errors are unbounded.
-    /// One particular case that could still be useful is sorting by
-    /// [min](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-min-aggregation.html) or
-    /// [max](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-max-aggregation.html)
-    /// aggregation: counts will not be accurate but at least the top buckets will be correctly picked.
+    /// > [error](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-terms-aggregation.html#search-aggregations-bucket-terms-aggregation-approximate-counts)
+    /// > on document counts. It is fine when a single shard is queried, or when the field that is
+    /// > being aggregated was used as a routing key at index time: in these cases results will be
+    /// > accurate since shards have disjoint values. However otherwise, errors are unbounded.
+    /// > One particular case that could still be useful is sorting by
+    /// > [min](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-min-aggregation.html) or
+    /// > [max](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-max-aggregation.html)
+    /// > aggregation: counts will not be accurate but at least the top buckets will be correctly picked.
     pub fn order<T>(mut self, order: T) -> Self
     where
         T: Into<TermsOrderCollection>,

src/search/aggregations/metrics/boxplot_aggregation.rs

@@ -12,7 +12,7 @@ use crate::{Aggregation, Number};
 /// [Computing Accurate Quantiles using T-Digests](https://github.com/tdunning/t-digest/blob/master/docs/t-digest-paper/histo.pdf)).
 ///
 /// > Boxplot as other percentile aggregations are also [non-deterministic](https://en.wikipedia.org/wiki/Nondeterministic_algorithm).
-/// This means you can get slightly different results using the same data.
+/// > This means you can get slightly different results using the same data.
 ///
 /// <https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-boxplot-aggregation.html>
 #[derive(Debug, Clone, Serialize, PartialEq)]

src/search/aggregations/metrics/max_aggregation.rs

@@ -5,8 +5,8 @@ use crate::util::*;
 /// numeric values extracted from the aggregated documents.
 ///
 /// > The `min` and `max` aggregation operate on the `double` representation of the data. As a
-/// consequence, the result may be approximate when running on longs whose absolute value is greater
-/// than `2^53`.
+/// > consequence, the result may be approximate when running on longs whose absolute value is greater
+/// > than `2^53`.
 ///
 /// <https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-max-aggregation.html>
 #[derive(Debug, Clone, Serialize, PartialEq)]

src/search/aggregations/metrics/min_aggregation.rs

@@ -5,8 +5,8 @@ use crate::util::*;
 /// values extracted from the aggregated documents.
 ///
 /// > The `min` and `max` aggregation operate on the `double` representation of the data. As a
-/// consequence, the result may be approximate when running on longs whose absolute value is greater
-/// than `2^53`.
+/// > consequence, the result may be approximate when running on longs whose absolute value is greater
+/// > than `2^53`.
 ///
 /// <https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-min-aggregation.html>
 #[derive(Debug, Clone, Serialize, PartialEq)]

src/search/aggregations/metrics/top_hits_aggregation.rs

@@ -6,9 +6,9 @@ use crate::util::*;
 /// so that the top matching documents can be aggregated per bucket.
 ///
 /// > We do not recommend using `top_hits` as a top-level aggregation.
-/// If you want to group search hits, use the
-/// [`collapse`](https://www.elastic.co/guide/en/elasticsearch/reference/current/collapse-search-results.html)
-/// parameter instead.
+/// > If you want to group search hits, use the
+/// > [`collapse`](https://www.elastic.co/guide/en/elasticsearch/reference/current/collapse-search-results.html)
+/// > parameter instead.
 ///
 /// The `top_hits` aggregation can effectively be used to group result sets
 /// by certain fields via a bucket aggregation. One or more bucket aggregations

src/search/aggregations/pipeline/mod.rs

@@ -4,11 +4,11 @@
 //!
 //! **Parent**
 //! > A family of pipeline aggregations that is provided with the output of its parent aggregation and is able
-//! to compute new buckets or new aggregations to add to existing buckets.
+//! > to compute new buckets or new aggregations to add to existing buckets.
 //!
 //! **Sibling**
 //! > Pipeline aggregations that are provided with the output of a sibling aggregation and are able to compute a
-//! new aggregation which will be at the same level as the sibling aggregation.
+//! > new aggregation which will be at the same level as the sibling aggregation.
 //!
 //! Pipeline aggregations can reference the aggregations they need to perform their computation by using the `buckets_path`
 //! parameter to indicate the paths to the required metrics. The syntax for defining these paths can be found in the
@@ -19,7 +19,7 @@
 //! (i.e. a derivative of a derivative).
 //!
 //! > **NOTE**: Because pipeline aggregations only add to the output, when chaining pipeline aggregations the output of each pipeline aggregation
-//! will be included in the final output.
+//! > will be included in the final output.
 //!
 //! <https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-pipeline.html>
 

src/search/highlight/boundary_scanner.rs

@@ -10,8 +10,8 @@ pub enum UnifiedBoundaryScanner {
     ///
     /// > **Warning**<br/>
     /// > The `sentence` scanner splits sentences bigger than `fragment_size` at the first word
-    /// boundary next to `fragment_size`. You can set `fragment_size` to 0 to never split any
-    /// sentence.
+    /// > boundary next to `fragment_size`. You can set `fragment_size` to 0 to never split any
+    /// > sentence.
     Sentence(Option<String>),
 
     /// Break highlighted fragments at the next word boundary, as determined by Java’s

src/search/highlight/highlighter.rs

@@ -66,18 +66,18 @@ pub struct DefaultHighlighter {
 /// highlighter:
 ///
 /// - Can be customized with a
-/// [boundary_scanner](https://www.elastic.co/guide/en/elasticsearch/reference/current/highlighting.html#boundary-scanners).
+///   [boundary_scanner](https://www.elastic.co/guide/en/elasticsearch/reference/current/highlighting.html#boundary-scanners).
 /// - Requires setting `term_vector` to `with_positions_offsets` which increases the size of the
-/// index
+///   index
 /// - Can combine matches from multiple fields into one result. See
-/// [`matched_fields`](FastVectorHighlighter::matched_fields)
+///   [`matched_fields`](FastVectorHighlighter::matched_fields)
 /// - Can assign different weights to matches at different positions allowing for things like
-/// phrase matches being sorted above term matches when highlighting a Boosting Query that boosts
-/// phrase matches over term matches
+///   phrase matches being sorted above term matches when highlighting a Boosting Query that boosts
+///   phrase matches over term matches
 ///
 /// > **Warning**<br/>
 /// > The `fvh` highlighter does not support span queries. If you need support for span queries,
-/// try an alternative highlighter, such as the `unified` highlighter.
+/// > try an alternative highlighter, such as the `unified` highlighter.
 ///
 /// <https://www.elastic.co/guide/en/elasticsearch/reference/current/highlighting.html#fast-vector-highlighter>
 #[derive(Debug, Clone, PartialEq, Serialize)]
@@ -144,12 +144,12 @@ pub struct FastVectorHighlighter {
 ///
 /// > **Warning**<br/>
 /// > The `plain` highlighter works best for highlighting simple query matches in a single field.
-/// To accurately reflect query logic, it creates a tiny in-memory index and re-runs the original
-/// query criteria through Lucene’s query execution planner to get access to low-level match
-/// information for the current document. This is repeated for every field and every document that
-/// needs to be highlighted. If you want to highlight a lot of fields in a lot of documents with
-/// complex queries, we recommend using the `unified` highlighter on `postings` or `term_vector`
-/// fields.
+/// > To accurately reflect query logic, it creates a tiny in-memory index and re-runs the original
+/// > query criteria through Lucene’s query execution planner to get access to low-level match
+/// > information for the current document. This is repeated for every field and every document that
+/// > needs to be highlighted. If you want to highlight a lot of fields in a lot of documents with
+/// > complex queries, we recommend using the `unified` highlighter on `postings` or `term_vector`
+/// > fields.
 ///
 /// <https://www.elastic.co/guide/en/elasticsearch/reference/current/highlighting.html#plain-highlighter>
 #[derive(Debug, Clone, PartialEq, Serialize)]
@@ -419,8 +419,8 @@ macro_rules! add_highlighter_methods {
         ///
         /// > **Warning**<br/>
         /// > Elasticsearch does not validate that `highlight_query` contains the search query in any
-        /// way so it is possible to define it so legitimate query results are not highlighted.
-        /// Generally, you should include the search query as part of the `highlight_query`.
+        /// > way so it is possible to define it so legitimate query results are not highlighted.
+        /// > Generally, you should include the search query as part of the `highlight_query`.
         pub fn highlight_query<T>(mut self, highlight_query: T) -> Self
         where
             T: Into<Query>,

src/search/highlight/mod.rs

@@ -12,28 +12,28 @@
 //! be obtained from:
 //!
 //! - The postings list. If `index_options` is set to `offsets` in the mapping, the
-//! [`unified` highlighter](UnifiedHighlighter) uses this information to highlight documents
-//! without re-analyzing the text. It re-runs the original query directly on the postings and
-//! extracts the matching offsets from the index, limiting the collection to the highlighted
-//! documents. This is important if you have large fields because it doesn’t require reanalyzing
-//! the text to be highlighted. It also requires less disk space than using `term_vectors`.
+//!   [`unified` highlighter](UnifiedHighlighter) uses this information to highlight documents
+//!   without re-analyzing the text. It re-runs the original query directly on the postings and
+//!   extracts the matching offsets from the index, limiting the collection to the highlighted
+//!   documents. This is important if you have large fields because it doesn’t require reanalyzing
+//!   the text to be highlighted. It also requires less disk space than using `term_vectors`.
 //! - Term vectors. If `term_vector` information is provided by setting `term_vector` to
-//! `with_positions_offsets` in the mapping, the [`unified` highlighter](UnifiedHighlighter)
-//! automatically uses the `term_vector` to highlight the field. It’s fast especially for large
-//! fields (> `1MB`) and for highlighting multi-term queries like `prefix` or `wildcard` because it
-//! can access the dictionary of terms for each document. The
-//! [`fvh` highlighter](FastVectorHighlighter) always uses term vectors.
+//!   `with_positions_offsets` in the mapping, the [`unified` highlighter](UnifiedHighlighter)
+//!   automatically uses the `term_vector` to highlight the field. It’s fast especially for large
+//!   fields (> `1MB`) and for highlighting multi-term queries like `prefix` or `wildcard` because it
+//!   can access the dictionary of terms for each document. The
+//!   [`fvh` highlighter](FastVectorHighlighter) always uses term vectors.
 //! - Plain highlighting. This mode is used by the [`unified`](UnifiedHighlighter) when there is no
-//! other alternative. It creates a tiny in-memory index and re-runs the original query criteria
-//! through Lucene’s query execution planner to get access to low-level match information on the
-//! current document. This is repeated for every field and every document that needs highlighting.
-//! The [`plain` highlighter](PlainHighlighter) always uses plain highlighting.
+//!   other alternative. It creates a tiny in-memory index and re-runs the original query criteria
+//!   through Lucene’s query execution planner to get access to low-level match information on the
+//!   current document. This is repeated for every field and every document that needs highlighting.
+//!   The [`plain` highlighter](PlainHighlighter) always uses plain highlighting.
 //!
 //! > **Warning**<br/>
 //! > Plain highlighting for large texts may require substantial amount of time and memory. To
-//! protect against this, the maximum number of text characters that will be analyzed has been
-//! limited to 1000000. This default limit can be changed for a particular index with the index
-//! setting `index.highlight.max_analyzed_offset`.
+//! > protect against this, the maximum number of text characters that will be analyzed has been
+//! > limited to 1000000. This default limit can be changed for a particular index with the index
+//! > setting `index.highlight.max_analyzed_offset`.
 //!
 //! <https://www.elastic.co/guide/en/elasticsearch/reference/current/highlighting.html>
 

src/search/knn/mod.rs

@@ -66,7 +66,7 @@ impl Knn {
     ///
     /// - `field` - The name of the vector field to search against. Must be a dense_vector field with indexing enabled.
     /// - `query_vector` - Query vector. Must have the same number of dimensions as the vector field you are searching
-    /// against.
+    ///   against.
     pub fn query_vector<T>(field: T, query_vector: Vec<f32>) -> Self
     where
         T: ToString,
@@ -174,8 +174,8 @@ impl From<TextEmbedding> for QueryVectorBuilder {
 impl TextEmbedding {
     /// Creates an instance of [`TextEmbedding`]
     /// - `model_id` - The ID of the text embedding model to use to generate the dense vectors from the query string.
-    /// Use the same model that generated the embeddings from the input text in the index you search against. You can
-    /// use the value of the deployment_id instead in the model_id argument.
+    ///   Use the same model that generated the embeddings from the input text in the index you search against. You can
+    ///   use the value of the deployment_id instead in the model_id argument.
     /// - `model_text` - The query string from which the model generates the dense vector representation.
     pub fn new<T, U>(model_id: T, model_text: U) -> Self
     where

src/search/queries/compound/boosting_query.rs

@@ -38,17 +38,17 @@ impl Query {
     ///
     /// - `positive` - Query you wish to run. Any returned documents must match this query.
     /// - `negative` - Query used to decrease the
-    /// [relevance score](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-filter-context.html#relevance-scores)
-    /// of matching documents.<br/>
-    /// If a returned document matches the `positive` query and this query, the `boosting` query
-    /// calculates the final
-    /// [relevance score](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-filter-context.html#relevance-scores)
-    /// for the document as follows:
+    ///   [relevance score](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-filter-context.html#relevance-scores)
+    ///   of matching documents.<br/>
+    ///   If a returned document matches the `positive` query and this query, the `boosting` query
+    ///   calculates the final
+    ///   [relevance score](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-filter-context.html#relevance-scores)
+    ///   for the document as follows:
     ///     1. Take the original relevance score from the `positive` query.
     ///     2. Multiply the score by the `negative_boost` value.
     /// - `negative_boost` - Floating point number between `0` and `1.0` used to decrease the
-    /// [relevance scores](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-filter-context.html#relevance-scores)
-    /// of documents matching the `negative` query.
+    ///   [relevance scores](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-filter-context.html#relevance-scores)
+    ///   of documents matching the `negative` query.
     pub fn boosting<Q, B>(positive: Q, negative: Q, negative_boost: B) -> BoostingQuery
     where
         Q: Into<Query>,