deno_bindgen

Clears the last open Dependabot alert on this repo. is unmaintained and has no patched release for its potential unaligned read advisory (GHSA-g98v-hv3f-hcfr, low), so the only fix is to stop depending on it. It reached the tree solely through 0.3, which pulls 2: atty 0.2.14 <- clap 2.34.0 <- structopt 0.3.26 <- deno_bindgen_cli has been deprecated since its derive macro was folded into 3 as , so the fix is to move to 4's derive API. That drops outright. The flag surface is unchanged. Verified by diffing before and after: , , , and all keep their names, shorts and help text. is passed explicitly in the attribute because clap 4 does not add implicitly the way structopt did. , which is what CI runs, passes. reports 11 pre-existing -class errors in , a crate this PR does not touch; they reproduce identically on an unmodified tree and CI does not run clippy.

0.3.17 -> 0.3.24 in and , fixing a use-after-free bug (GHSA-f95p-4cv5-8w8x, low) The advisory (GHSA-g98v-hv3f-hcfr, low) in is left unfixed: is unmaintained and no patched release exists on crates.io, so there is nothing can pull in. It is a transitive dependency of via 2.x, pulled in by .

I originally provided a PR https://github.com/denoland/deno_bindgen/pull/82 (merged) for this issue: https://github.com/denoland/deno_bindgen/issues/72 I have since discovered more about Rust compilation and procedural macros and realised my "fix" doesn't work as per this: https://github.com/rust-lang/docs.rs/issues/1823 The two issues with attempting to use : OUT_DIR is not defined when running any type of cargo build except when a exists. if OUT_DIR is defined (because a exists), the will output to as expected, but the does not have OUT_DIR defined and will default to looking for in the current working folder. I also see that my "fix" introduced another issue which was fixed here: https://github.com/denoland/deno_bindgen/pull/89 After learning more and understanding more... I humbly submit a PR which: rolls back the non-working fix: https://github.com/denoland/deno_bindgen/pull/82 rolls back the additional fix required for my non-working fix: https://github.com/denoland/deno_bindgen/pull/89 fixes a typo in the docs On my journey, I have also discovered that the issue of procedural macros having side-effects has been discussed elsewhere: https://github.com/rust-lang/cargo/issues/9084 It would seem this issue is a general issue with using procedural macros for outputting auxiliary data and out of my league in terms of resolving. I am not sure what the solution is, but for now I will have to put up with the fact that when my project makes use of deno_bindgen I can't refer to the generated Rust docs on docs.rs...