Regression in crate ipfs-api on 1.30 beta

[leoyvens]

The crate ipfs-api on version 0.5.0-alpha2 builds fine on stable. On beta and nightly fails with 84 name resolution errors. There are multiple instances of this error:

error: cannot determine resolution for the attribute macro `serde`
  --> ipfs-api/src/response/pin.rs:22:3
   |
22 | #[serde(rename_all = "PascalCase")]
   |   ^^^^^
   |
   = note: import resolution is stuck, try simplifying macro imports

Ping @petrochenkov who is an expert here.
Ping crate author @ferristseng.

[pnkfelix]

visiting for triage. P-high.

[nikomatsakis]

It would be great to bisect this with https://github.com/rust-lang-nursery/cargo-bisect-rustc

[pnkfelix]

Assigning @petrochenkov (but they should feel free to unassign themselves if they are unable to commit time to this.)

[eddyb]

It might be caused by the explicit import of something named serde:

use response::serde;
// ...
#[derive(Debug, Deserialize)]
#[serde(rename_all = "PascalCase")]
pub struct PinAddResponse {

EDIT: response glob-imports all of their children's contents.

[pietroalbini]

Crater found more regressions similar to this.

 error: cannot determine resolution for the attribute macro `serde`
   --> src/response/bitswap.rs:12:3
    |
 12 | #[serde(rename_all = "PascalCase")]
    |   ^^^^^
    |
    = note: import resolution is stuck, try simplifying macro imports

 error: cannot determine resolution for the macro `json`
    --> src/models/data.rs:179:19
     |
 179 |         let obj = json!({
     |                   ^^^^
     |
     = note: import resolution is stuck, try simplifying macro imports

• Dependencies of ipfs-api:
  • world_id 0.1.0 (depends on ipfs-api) regressed from stable to beta (build log) cc @icefoxen
• libyobicash 0.3.2 regressed from stable to beta (build log) cc @chritchens
• devnought/gitplz regressed from stable to beta (build log) cc @devnought

cc @petrochenkov

[devnought]

• devnought/gitplz regressed from stable to beta (build log) cc @devnought

I was surprised to wake up to this today as I thought crater only ran against crates published on crates.io, which gitplz isn't.

In any case, I have a rust-2018 branch that uses the edition and compiles on the latest nightly.

EDIT I've merged my rust-2018 changes over to master. This crate shouldn't be a problem on the next crater run.

[pietroalbini]

I was surprised to wake up to this today as I thought crater only ran against crates published on crates.io, which gitplz isn't.

We also test repositories on GitHub :D