Adding upstream version 115.7.0esr.upstream/115.7.0esr

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

2 files changed, 204 insertions, 0 deletions

diff --git a/third_party/rust/darling/src/lib.rs b/third_party/rust/darling/src/lib.rs
new file mode 100644
index 0000000000..b2be36d0cb
--- /dev/null
+++ b/third_party/rust/darling/src/lib.rs
@@ -0,0 +1,108 @@
+//! # Darling
+//! Darling is a tool for declarative attribute parsing in proc macro implementations.
+//!
+//!
+//! ## Design
+//! Darling takes considerable design inspiration from [`serde`](https://serde.rs). A data structure that can be
+//! read from any attribute implements `FromMeta` (or has an implementation automatically
+//! generated using `derive`). Any crate can provide `FromMeta` implementations, even one not
+//! specifically geared towards proc-macro authors.
+//!
+//! Proc-macro crates should provide their own structs which implement or derive `FromDeriveInput`,
+//! `FromField`, `FromVariant`, `FromGenerics`, _et alia_ to gather settings relevant to their operation.
+//!
+//! ## Attributes
+//! There are a number of attributes that `darling` exposes to enable finer-grained control over the code
+//! it generates.
+//!
+//! * **Field renaming**: You can use `#[darling(rename="new_name")]` on a field to change the name Darling looks for.
+//!   You can also use `#[darling(rename_all="...")]` at the struct or enum level to apply a casing rule to all fields or variants.
+//! * **Map function**: You can use `#[darling(map="path::to::function")]` to run code on a field before its stored in the struct.
+//! * **Default values**: You can use `#[darling(default)]` at the type or field level to use that type's default value to fill
+//!   in values not specified by the caller.
+//! * **Skipped fields**: You can skip a variant or field using `#[darling(skip)]`. Fields marked with this will fall back to
+//!   `Default::default()` for their value, but you can override that with an explicit default or a value from the type-level default.
+//!
+//! ## Forwarded Fields
+//! All derivable traits except `FromMeta` support forwarding some fields from the input AST to the derived struct.
+//! These fields are matched up by identifier **before** `rename` attribute values are considered,
+//! allowing you to use their names for your own properties.
+//! The deriving struct is responsible for making sure the types of fields it chooses to declare are compatible with this table.
+//!
+//! A deriving struct is free to include or exclude any of the fields below.
+//!
+//! ### `FromDeriveInput`
+//! |Field name|Type|Meaning|
+//! |---|---|---|
+//! |`ident`|`syn::Ident`|The identifier of the passed-in type|
+//! |`vis`|`syn::Visibility`|The visibility of the passed-in type|
+//! |`generics`|`T: darling::FromGenerics`|The generics of the passed-in type. This can be `syn::Generics`, `darling::ast::Generics`, or any compatible type.|
+//! |`data`|`darling::ast::Data`|The body of the passed-in type|
+//! |`attrs`|`Vec<syn::Attribute>`|The forwarded attributes from the passed in type. These are controlled using the `forward_attrs` attribute.|
+//!
+//! ### `FromField`
+//! |Field name|Type|Meaning|
+//! |---|---|---|
+//! |`ident`|`Option<syn::Ident>`|The identifier of the passed-in field, or `None` for tuple fields|
+//! |`vis`|`syn::Visibility`|The visibility of the passed-in field|
+//! |`ty`|`syn::Type`|The type of the passed-in field|
+//! |`attrs`|`Vec<syn::Attribute>`|The forwarded attributes from the passed in field. These are controlled using the `forward_attrs` attribute.|
+//!
+//! ### `FromTypeParam`
+//! |Field name|Type|Meaning|
+//! |---|---|---|
+//! |`ident`|`syn::Ident`|The identifier of the passed-in type param|
+//! |`bounds`|`Vec<syn::TypeParamBound>`|The bounds applied to the type param|
+//! |`default`|`Option<syn::Type>`|The default type of the parameter, if one exists|
+//! |`attrs`|`Vec<syn::Attribute>`|The forwarded attributes from the passed in type param. These are controlled using the `forward_attrs` attribute.|
+//!
+//! ### `FromVariant`
+//! |Field name|Type|Meaning|
+//! |---|---|---|
+//! |`ident`|`syn::Ident`|The identifier of the passed-in variant|
+//! |`discriminant`|`Option<syn::Expr>`|For a variant such as `Example = 2`, the `2`|
+//! |`fields`|`darling::ast::Fields<T> where T: FromField`|The fields associated with the variant|
+//! |`attrs`|`Vec<syn::Attribute>`|The forwarded attributes from the passed in variant. These are controlled using the `forward_attrs` attribute.|
+
+extern crate core;
+
+#[allow(unused_imports)]
+#[macro_use]
+extern crate darling_macro;
+
+#[doc(hidden)]
+pub use darling_macro::*;
+
+#[doc(inline)]
+pub use darling_core::{
+    FromAttributes, FromDeriveInput, FromField, FromGenericParam, FromGenerics, FromMeta,
+    FromTypeParam, FromVariant,
+};
+
+#[doc(inline)]
+pub use darling_core::{Error, Result};
+
+#[doc(inline)]
+pub use darling_core::{ast, error, usage, util};
+
+// XXX exported so that `ExtractAttribute::extractor` can convert a path into tokens.
+// This is likely to change in the future, so only generated code should depend on this export.
+#[doc(hidden)]
+pub use darling_core::ToTokens;
+
+/// Core/std trait re-exports. This should help produce generated code which doesn't
+/// depend on `std` unnecessarily, and avoids problems caused by aliasing `std` or any
+/// of the referenced types.
+#[doc(hidden)]
+pub mod export {
+    pub use core::convert::From;
+    pub use core::default::Default;
+    pub use core::option::Option::{self, None, Some};
+    pub use core::result::Result::{self, Err, Ok};
+    pub use darling_core::syn;
+    pub use std::string::ToString;
+    pub use std::vec::Vec;
+}
+
+#[macro_use]
+mod macros_public;
diff --git a/third_party/rust/darling/src/macros_public.rs b/third_party/rust/darling/src/macros_public.rs
new file mode 100644
index 0000000000..c264fcc2a8
--- /dev/null
+++ b/third_party/rust/darling/src/macros_public.rs
@@ -0,0 +1,96 @@
+//! Macros that should be exported from both `darling_core` and `darling`.
+//! Note that these are **sym-linked** into the main code, and so cannot declare on items that are exported differently
+//! in `darling_core` vs. `darling`.
+
+/// Generator for `UsesTypeParam` impls that unions the used type parameters of the selected fields.
+///
+/// # Usage
+/// The macro takes the type implementing the trait as the first argument, then a comma-separated list of
+/// fields for the rest of its arguments.
+///
+/// The type of each passed-in field must implement `UsesTypeParams`, or the resulting code won't compile.
+///
+/// ```rust
+/// # extern crate syn;
+/// # use darling_core::uses_type_params;
+/// #
+/// struct MyField {
+///     ty: syn::Type,
+/// }
+///
+/// uses_type_params!(MyField, ty);
+///
+/// fn main() {
+///     // no test run
+/// }
+/// ```
+///
+/// `darling` cannot derive this trait automatically, as it doesn't know which information extracted from
+/// proc-macro input is meant to constitute "using" the type parameter, but crate consumers should
+/// implement it by hand or using the macro.
+#[macro_export]
+macro_rules! uses_type_params {
+    ($impl_type:ty, $accessor:ident) => {
+        impl $crate::usage::UsesTypeParams for $impl_type {
+            fn uses_type_params<'gen>(
+                &self,
+                options: &$crate::usage::Options,
+                type_set: &'gen $crate::usage::IdentSet
+            ) -> $crate::usage::IdentRefSet<'gen> {
+                self.$accessor.uses_type_params(options, type_set)
+            }
+        }
+    };
+    ($impl_type:ty, $first:ident, $($field:ident),+) => {
+        impl $crate::usage::UsesTypeParams for $impl_type {
+            fn uses_type_params<'gen>(
+                &self,
+                options: &$crate::usage::Options,
+                type_set: &'gen $crate::usage::IdentSet
+            ) -> $crate::usage::IdentRefSet<'gen> {
+                let mut hits = self.$first.uses_type_params(options, type_set);
+                $(
+                    hits.extend(self.$field.uses_type_params(options, type_set));
+                )*
+                hits
+            }
+        }
+    };
+}
+
+/// Generator for `UsesLifetimes` impls that unions the used lifetimes of the selected fields.
+///
+/// # Usage
+/// The macro takes the type implementing the trait as the first argument, then a comma-separated list of
+/// fields for the rest of its arguments.
+///
+/// The type of each passed-in field must implement `UsesLifetimes`, or the resulting code won't compile.
+#[macro_export]
+macro_rules! uses_lifetimes {
+    ($impl_type:ty, $accessor:ident) => {
+        impl $crate::usage::UsesLifetimes for $impl_type {
+            fn uses_lifetimes<'gen>(
+                &self,
+                options: &$crate::usage::Options,
+                type_set: &'gen $crate::usage::LifetimeSet
+            ) -> $crate::usage::LifetimeRefSet<'gen> {
+                self.$accessor.uses_lifetimes(options, type_set)
+            }
+        }
+    };
+    ($impl_type:ty, $first:ident, $($field:ident),+) => {
+        impl $crate::usage::UsesLifetimes for $impl_type {
+            fn uses_lifetimes<'gen>(
+                &self,
+                options: &$crate::usage::Options,
+                type_set: &'gen $crate::usage::LifetimeSet
+            ) -> $crate::usage::LifetimeRefSet<'gen> {
+                let mut hits = self.$first.uses_lifetimes(options, type_set);
+                $(
+                    hits.extend(self.$field.uses_lifetimes(options, type_set));
+                )*
+                hits
+            }
+        }
+    };
+}