num-derive

chore: Release num-derive version 0.5.1

• Remove mention of the old "full-syntax" feature.

chore: Release num-derive version 0.5.0

• Upgrade to syn v3.
  • This raises the minimum supported rustc to 1.71.

• Use anon-const to avoid RFC 3373 warnings.

• Make Float work with no_std -- thanks @vkahl!
• Emit full paths for Option and Result.
• Add derive macro for num_traits::Signed and Unsigned -- thanks @tdelabro!

chore: Release num-derive version 0.4.0

• Update to syn-2 -- thanks @maurer!
  • This raises the minimum supported rustc to 1.56.
  • The "full-syntax" feature has also been removed.

• Make NumOps work with no_std -- thanks @jedrzejboczar!

• Add #[inline] to all derived functions -- thanks @Amanieu!

• Add num_traits proc_macro helper for explicit import - thanks @jean-airoldie!
• Provide nicer parse errors and suggest "full-syntax"

• Updated the proc-macro2, quote, and syn dependencies to 1.0, which raises the minimum supported rustc to 1.31.

• Improved the masking of lints in derived code.

• Adjusted dependencies to allow no-std targets.

• Added newtype deriving for FromPrimitive, ToPrimitive, NumOps<Self, Self>, NumCast, Zero, One, Num, and Float. Thanks @asayers!

• Updated dependencies.

• Updated dependencies -- thanks @spearman!

• Discriminant matching is now simplified, casting values directly by name, rather than trying to compute offsets from known values manually.
• breaking change: Derivations now import the traits from num-traits instead of the full num crate. These are still compatible, but users need to have an explicit num-traits = "0.2" dependency in their Cargo.toml.

• The derived code now explicitly allows unused_qualifications, so users that globally deny that lint don't encounter an error.

• The derived code now explicitly allows trivial_numeric_casts, so users that globally deny that lint don't encounter an error.

• num-derive now has its own source repository at rust-num/num-derive.
• The derivation macros have been updated to using syn 0.12. Support for complex expressions in enum values can be enabled with the full-syntax feature.

Thanks to @cuviper and @hcpl for their contributions!