Update proc-macro-error to an alternative because it is unmaintained #1201

Closed BaptisteRoseau closed 1 week ago

While running cargo deny on a project it seems like proc-macro-error is used in utoipa even though it is not maintained anymore:

$ cargo deny check --allow duplicate --allow unlicensed
warning[unmaintained]: proc-macro-error is unmaintained
    ┌─ (edited)/Cargo.lock:281:1
    │
281 │ proc-macro-error 1.0.4 registry+https://github.com/rust-lang/crates.io-index
    │ ---------------------------------------------------------------------------- unmaintained advisory detected
    │
    = ID: RUSTSEC-2024-0370
    = Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0370
    = proc-macro-error's maintainer seems to be unreachable, with no commits for 2 years, no releases pushed for 4 years, and no activity on the GitLab repo or response to email.

      proc-macro-error also depends on `syn 1.x`, which may be bringing duplicate dependencies into dependant build trees.

      ## Possible Alternative(s)

      - [manyhow](https://crates.io/crates/manyhow)
      - [proc-macro-error2](https://crates.io/crates/proc-macro-error2)
      - [proc-macro2-diagnostics](https://github.com/SergioBenitez/proc-macro2-diagnostics)
    = Announcement: https://gitlab.com/CreepySkeleton/proc-macro-error/-/issues/20
    = Solution: No safe upgrade is available!
    = proc-macro-error v1.0.4
      └── utoipa-gen v4.3.1
          └── utoipa v4.2.3
         (my crates)

Maybe switching to an actively maintained crate can be done without breaking anything, would it be possible to try switching to one of the listed alternatives ?

This is a duplicate for #1105, #1028 and #854 and has been already long ago fixed in here #920. Reason you might be experiencing this error is that some of the dependencies might rely on proc-macro-error to which utoipa provides the feature flag for. E.g. https://github.com/juhaku/utoipa/issues/1028#issuecomment-2332906698 see below

This dep is coming into the lock file via rust_decimal, via borsh which directly depends on the problem crate, and I have raised https://github.com/Kyuuhachi/syn_derive/issues/4 . I think this won't affect many utoipa uses, and there is nothing utoipa can do to fix it, so closing.

This issue is coming because the lockfile contains proc-macro-error while utoipa itself does not depend on it. From utoipas perspective there is nothing that can be done really. Instead the dependencies that still rely on the proc-macro-error should migrate out from it. You can list the dependency tree with cargo tree --format {p} {f} and try to find the crate that actually depends on the proc-macro-error.

Thank you for the explanation. I have searched for this issue before posting it but did not find the duplicates, my apologies.

I will dig a bit deeper to point out which crate uses proc-macro-error, so far it seems to be utoipa-gen, which is weird as it's not listed your Cargo.toml.

$ cargo tree --format "{p} {f}" | grep -B5 proc-macro-error
│   ├── utoipa v4.2.3 axum_extras,default,uuid
│   │   ├── indexmap v2.6.0 default,serde,std (*)
│   │   ├── serde v1.0.214 alloc,default,derive,serde_derive,std (*)
│   │   ├── serde_json v1.0.132 default,raw_value,std,unbounded_depth (*)
│   │   └── utoipa-gen v4.3.1 (proc-macro) axum_extras,regex,uuid
│   │       ├── proc-macro-error v1.0.4 default,syn,syn-error
│   │       │   ├── proc-macro-error-attr v1.0.4 (proc-macro)

I may have missed something, thanks for your time and explanation, have a great day.

It seems that you are using utoipa-4.2.3 which has been released before the #920 has been merged to master. You need to upgrade to 5.x.x in order to get the proc-macro-error free approach.

juhaku / utoipa

Update proc-macro-error to an alternative because it is unmaintained #1201