Skip to content

[1.30 beta] Unresolved import errors in a few crates #54471

Description

@emilyalbini

Some crates are failing in 1.30 beta with errors like this one:

 error[E0432]: unresolved import `geometry::Isometry`
   --> /cargo-home/registry/src/github.com-1ecc6299db9ec823/nalgebra-0.15.3/src/base/cg.rs:15:16
    |
 15 | use geometry::{Isometry, IsometryMatrix3, Orthographic3, Perspective3, Point, Point3, Rotation2,
    |                ^^^^^^^^ no `Isometry` in `geometry`. Did you mean to use `isometry`?

cc @petrochenkov

Activity

  1. added
    A-resolveArea: Name/path resolution done by `rustc_resolve` specifically
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    C-bugCategory: This is a bug.
    on Sep 22, 2018
  2. added this to the 1.30 milestone on Sep 22, 2018
  3. self-assigned this
    on Sep 22, 2018
  4. petrochenkov commented on Sep 23, 2018

    @petrochenkov
    Contributor

    The root issue is in the nalgebra crate and it's something that was fixed between nalgebra 0.16.0 and nalgebra 0.16.1.

    EDIT: nalgebra 0.16.1 removed use serde; imports, almost certainly as a response to this regression.

  5. icefoxen commented on Sep 23, 2018

    @icefoxen
    Contributor

    The ipfs-api crate does not use nlagebra at all. All of these build logs seem to have something wrong with serde involved; for example, ipfs-api gets a lot of errors associated with its use of #[serde(rename_all = "PascalCase")], along the lines of:

    
    Sep 21 17:09:54.166 INFO kablam! error: cannot determine resolution for the attribute macro `serde`
    Sep 21 17:09:54.166 INFO kablam!   --> /cargo-home/registry/src/github.com-1ecc6299db9ec823/nalgebra-0.15.3/src/linalg/symmetric_tridiagonal.rs:16:5
    Sep 21 17:09:54.166 INFO kablam!    |
    Sep 21 17:09:54.166 INFO kablam! 16 |     serde(
    Sep 21 17:09:54.166 INFO kablam!    |     ^^^^^
    Sep 21 17:09:54.166 INFO kablam!    |
    Sep 21 17:09:54.166 INFO kablam!    = note: import resolution is stuck, try simplifying macro imports
    

    All the other build logs appear to have "undefined type or module" along with the error import resolution is stuck, try simplifying macro imports. Removing the serde annotations from ipfs-api lets it build successfully, though the protocol it speaks is then incorrect.

  6. petrochenkov commented on Sep 23, 2018

    @petrochenkov
    Contributor

    Yes, ipfs-api is a separate case (probably with the same underlying issue in rustc) and it's already tracked separately in #54386, the other regressed crates use nalgebra.

  7. icefoxen commented on Sep 23, 2018

    @icefoxen
    Contributor

    Aha, thanks!

  8. petrochenkov commented on Sep 23, 2018

    @petrochenkov
    Contributor

    Minimized:

    #![allow(unused)]
    
    #[macro_use]
    extern crate serde_derive;
    
    use self::one::*;
    use self::two::*;
    
    mod serde {}
    
    mod one {
        use serde;
    
        #[derive(Serialize)]
        #[serde]
        struct One;
    }
    
    mod two {
        use serde;
    
        #[derive(Serialize)]
        #[serde]
        struct Two;
    }
    
    fn main() {}
  9. petrochenkov commented on Sep 24, 2018

    @petrochenkov
    Contributor

    Fixed in #54518
    All the crates listed in #54471 (comment) build successfully now.

  10. added a commit that references this issue on Sep 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-resolveArea: Name/path resolution done by `rustc_resolve` specificallyC-bugCategory: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-betaPerformance or correctness regression from stable to beta.

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions