Build broken with " `parse_quote_spanned` is ambiguous"

1

I'm a bit grumpy with Rust this morning, grrr, I have a little program that has been building and running fine for ages but has not been touched for six months. This morning I try to build it and get an error:

   Compiling serde v1.0.114
error[E0659]: `parse_quote_spanned` is ambiguous
   --> /Users/zicog/.cargo/registry/src/github.com-1ecc6299db9ec823/pin-project-internal-0.4.22/src/pin_project/derive.rs:859:67
    |
859 |                 proj_generics.make_where_clause().predicates.push(parse_quote_spanned! { span =>
    |                                                                   ^^^^^^^^^^^^^^^^^^^ ambiguous name
    |
    = note: ambiguous because of a conflict between a `macro_rules` name and a non-`macro_rules` name from another module
note: `parse_quote_spanned` could refer to the macro defined here
   --> /Users/zicog/.cargo/registry/src/github.com-1ecc6299db9ec823/pin-project-internal-0.4.22/src/utils.rs:22:1

Here is my Cargo.toml:

[package]
name = "conq_serial_gateway"
version = "0.1.0"
authors = ["zicog <zicog@idhkhsadkl.com>"]
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
tokio = { version = "0.2", features = ["full"] }
tokio-serial = "4.3.3-tokio-0.2.0-alpha.6"
nats = "0.6.0"
custom_error = "1.7.1"
log = "0.4"
env_logger = "0.7.1"
clap = "2.33.3"
#chrono = "0.4.22"

Updating to :

tokio = { version = "1.20.1", features = ["full"] }
tokio-serial = "5.4.3"

Gives me the same error elsewhere:

   Compiling pin-project-internal v0.4.22
error[E0659]: `parse_quote_spanned` is ambiguous
   --> /Users/zicog/.cargo/registry/src/github.com-1ecc6299db9ec823/pin-project-internal-0.4.22/src/pin_project/derive.rs:859:67
    |
859 |                 proj_generics.make_where_clause().predicates.push(parse_quote_spanned! { span =>
    |                                                                   ^^^^^^^^^^^^^^^^^^^ ambiguous name
    |
    = note: ambiguous because of a conflict between a `macro_rules` name and a non-`macro_rules` name from another module
note: `parse_quote_spanned` could refer to the macro defined here
   --> /Users/zicog/.cargo/registry/src/github.com-1ecc6299db9ec823/pin-project-internal-0.4.22/src/utils.rs:22:1

Of course thins have changed since 6 months ago. I'm now on todays stable compiler: stable-aarch64-apple-darwin unchanged - rustc 1.63.0 (4b91a6ea7 2022-08-08)

Trying to use nightly gets me a totally different error:

   Compiling num_cpus v1.13.0
error[E0512]: cannot transmute between types of different sizes, or dependently-sized types
   --> /Users/zicogl/.cargo/registry/src/github.com-1ecc6299db9ec823/socket2-0.3.12/src/sockaddr.rs:176:9
    |
176 |         mem::transmute::<SocketAddrV4, sockaddr_in>(v4);
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: source type: `SocketAddrV4` (48 bits)
    = note: target type: `sockaddr_in` (128 bits)

Grrr... anyone got any ideas about this? I don't really want have to go back to whatever compiler version worked half a year ago.

2

I tried to replicate the issue on my system, but I get this error:

error: no matching package named `signatory-dalek` found
location searched: registry `crates-io`
required by package `nkeys v0.0.9`
    ... which satisfies dependency `nkeys = "^0.0.9"` of package `nats v0.6.0`
    ... which satisfies dependency `nats = "^0.6.0"` of package `conq_serial_gateway v0.1.0

Looks like that package has been yanked?

Anyway, looking at the issues:

This looks like Ambiguous macro use does not compile · Issue #337 · taiki-e/pin-project · GitHub it's due to syn adding a macro with the same name which conflicts with pin-project-internal. The fix is to update the version of pin-project automatically selected by running cargo update.

This one can also be solved by running cargo update to update socket2 to at least the version 0.3.16. It was wrongly relying on the internal representation of the SocketAddrV4 type which changed recently and broke transmutes. See also https://github.com/rust-lang/rust/pull/78802

2 Likes
3

I don’t know whether using an old compiler would address your issue, even short term. But, if you aren’t already aware, you might be interested to know that it is relatively easy to use a specific rust toolchain only for a specific project with a rust-toolchain.toml file.

I recently used one of those to get a working build of a project that used the now unmaintained cargo-web subcommand so I could port it to use contemporary tooling.

4

Thanks all.

Unfortunately I had already been doing cargo update but it did not help.

So I started going through my Cargo.toml and manually updating things to the latest versions I see on crates.io.

Turned out that updating nats to 0.23.0 got the thing to build. Shouldn't cargo update have done that already?

Also unfortunately when I manually change tokio and to the current 1.20.1 and Tokyo-serial to 5.4.1 all hell breaks loose as the API seems to have changed.

error[E0432]: unresolved import `tokio_serial::Serial`
  --> src/lib.rs:14:5
   |
14 | use tokio_serial::Serial;
   |     ^^^^^^^^^^^^^^^^^^^^ no `Serial` in the root

error[E0433]: failed to resolve: could not find `Serial` in `tokio_serial`
   --> src/lib.rs:288:30
    |
288 |     let port = tokio_serial::Serial::from_path(&tty_path, &settings)?;
    |                              ^^^^^^ could not find `Serial` in `tokio_serial`

error[E0425]: cannot find function `delay_for` in module `tokio::time`
   --> src/lib.rs:102:26
    |
102 |             tokio::time::delay_for(Duration::from_millis(1000)).await;
    |                          ^^^^^^^^^ not found in `tokio::time`

error[E0422]: cannot find struct, variant or union type `SerialPortSettings` in crate `tokio_serial`
   --> src/lib.rs:283:34
    |
283 |     let settings = tokio_serial::SerialPortSettings {
    |                                  ^^^^^^^^^^^^^^^^^^ not found in `tokio_serial`

So I'm still grumpy. tokio and tokio_serial have always given me grief about what versions work with what over the years so I'm doubly grumpy....

5

0.x.z and 0.y.z are treated by Cargo as incompatible, so updating 0.6.0 to 0.23.0 automatically isn't safe, therefore cargo update doesn't do it.

6

Ah OK. I can feel less grumpy about that. Thanks.

7

I'm having the same issue after trying to update async_trait to version 0.1.57 from 0.1.50. Reverting didn't help and I have tried clearing cargo's cache with cargo clean and even reinstalling cargo.

Edit:

Somehow the version 0.1.57 of async_trait got stucked in cargo.lock, so removing the file and recreating it did the trick.

1 Like
8

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.