summaryrefslogtreecommitdiffstats
path: root/rust/vendor/nom-derive/UPGRADING.md
diff options
context:
space:
mode:
Diffstat (limited to 'rust/vendor/nom-derive/UPGRADING.md')
-rw-r--r--rust/vendor/nom-derive/UPGRADING.md69
1 files changed, 69 insertions, 0 deletions
diff --git a/rust/vendor/nom-derive/UPGRADING.md b/rust/vendor/nom-derive/UPGRADING.md
new file mode 100644
index 0000000..db5a82d
--- /dev/null
+++ b/rust/vendor/nom-derive/UPGRADING.md
@@ -0,0 +1,69 @@
+## Upgrading to 0.9
+
+### Generalization of the Parse trait
+
+`nom-derive` now generates an implementation of the `Parse` trait when possible (when there are no selector or extra args).
+The methods `parse_be` and `parse_le` are both generated (unless endianness is fixed), and will recursively call
+similarly named methods in child objects.
+
+There are two possibilities:
+ - the object can be represented (and parsed) differently, depending on the endianness
+ - the object always have the same representation, and does not depend on the endianness (most common case)
+
+If the object always have the same parsing, then the endianness should be fixed. This can be done by using the `NomBE`
+or `NomLE` custom derive instead of `Nom`, or by applying the `BigEndian` or `LittleEndian` top-level attributes.
+
+If the object can has different representations, then the `Nom` custom derive should be used.
+
+Additionally, calling the parsing methods requires the `Parse` trait, so callers must import it:
+```rust
+use nom_derive::Parse;
+```
+
+### Manual implementations of the `parse` method
+
+If you have manually implemented or called `parse` methods, you should convert them to implementations of the `Parse`
+trait.
+
+There are two possibilities:
+ - object does not depend on endianness: only the `parse` method of the trait should be implemented
+ - object has different representations: both `parse_be` and `parse_le` should be implemented
+
+For example:
+
+```rust
+impl OspfLinkStateAdvertisement {
+ pub fn parse(input: &[u8]) -> IResult<&[u8], OspfLinkStateAdvertisement> {
+ ...
+ }
+}
+```
+
+An OSPF packet is always represented as big-endian, so this becomes:
+
+```rust
+impl<'a> Parse<&'a [u8]> for OspfLinkStateAdvertisement {
+ fn parse(input: &'a [u8]) -> IResult<&'a [u8], OspfLinkStateAdvertisement> {
+ ...
+ }
+}
+```
+
+In most cases, that means only changing the `impl` statement and removing the `pub` keyword.
+
+## Upgrading to 0.8
+
+### The Parse trait
+
+The trait `Parse` has been introduced in 0.8.0. This trait is used to provide a common interface, and default implementations for primitive types.
+
+As a consequence, it must be imported as well as the custom derive attribute:
+`use nom_derive::Nom` now often becomes `use nom_derive::{Nom, Parse}` or `use nom_derive::*`.
+
+### Order of attributes
+
+`nom-derive` will now apply attributes in order of appearance to build a parse tree.
+
+For example, if specifying both `Count` and `Cond` attributes:
+- `Count="4", Cond(a > 0)` is built as `Count(4, Cond(a> 0, T::Parse))`, which means a type `Vec<Option<T>>` is expected
+- `Cond(a > 0), Count="4"` is built as `Cond(a> 0, Count(4, T::Parse))`, which means a type `Option<Vec<T>>` is expected