Updating from 0.25.3 to 0.26.x or 0.27.x fails for interface

[pierre-wehbe]

Env:

nightly-aarch64-apple-darwin - Up to date : 1.80.0-nightly (867900499 2024-05-23) uniffi 0.27.2

The following works

/// Example
namespace example {
  /// Hello Rust
  string hello_world();
};

/// Example Enum
enum ExampleEnum {
  "v1",
  "v2",
};


/// Glucose
dictionary Glucose {
    f32 raw;
    timestamp timestamp;
    timestamp local_timestamp;
};

Adding the following fails:

// lib.rs
pub struct TodoList;

impl TodoList {
    fn new() -> Self {
        TodoList {
        }
    }
}

// udl file
/// TodoList
interface TodoList {
    constructor();
};

The error is:

error[E0433]: failed to resolve: could not find `marker` in `core`
  --> <hidden>/cross_platform/target/debug/build/example-904b99f23226f7e3/out/example.uniffi.rs:69:1
   |
69 | #[::uniffi::derive_object_for_udl]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ could not find `marker` in `core`

   |
   = note: this error originates in the attribute macro `::uniffi::derive_object_for_udl` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing this module
  --> src/lib.rs:1:1
   |
1  + use std::marker;
   |

This is the content of example.uniffi.rs:69:1

#[::uniffi::derive_object_for_udl]
struct r#TodoList { }
#[::uniffi::export_for_udl]
impl r#TodoList {
    #[uniffi::constructor]
    pub fn r#new(
    ) -> std::sync::Arc<r#TodoList>
    {
        unreachable!()
    }
}

[pierre-wehbe]

@rogerneel ^

[badboy]

I assume you mean 0.25, etc. (there's no v2.x yet)

[badboy]

I cannot reproduce this locally. Code inline below. Tested with 0.25, 0.26 and 0.27. All compiles, targetting the host architecture. The proc macros correctly use ::core::*. Given that's ... the core library it should exist.

If you can providing the failing code in a git repository would help us debug this further.

lib.rs:

use std::time::SystemTime;

#[allow(non_camel_case_types)]
pub enum ExampleEnum {
    v1, v2
}

pub struct Glucose {
    raw: f32,
    timestamp: SystemTime,
    local_timestamp: SystemTime,
}

pub fn hello_world() -> String {
    String::from("hello world")
}

pub struct TodoList;

impl TodoList {
    fn new() -> Self {
        TodoList {
        }
    }
}

uniffi::include_scaffolding!("uniffi-bug-test");

UDL:

namespace uniffi_bug_test {
  /// Hello Rust
  string hello_world();
};

/// Example Enum
enum ExampleEnum {
  "v1",
  "v2",
};


/// Glucose
dictionary Glucose {
    f32 raw;
    timestamp timestamp;
    timestamp local_timestamp;
};

/// TodoList
interface TodoList {
    constructor();
};

[pierre-wehbe]

@badboy thanks for looking into it, I'll try building a repo that reproduces the issue.

I failed to mention some information:

• It runs fine on 0.25.x
• here is what our Cargo.toml looks like, could it be possible us having a local "core" crate causes some namespace clashing?

...
[dependencies]
uniffi = { version = "0.27.2", features = [ "cli" ] }
shared = { path = "../rust/shared" }
core = { path = "../rust/core" }

[build-dependencies]
uniffi = { version = "0.27.2", features = [ "build" ] }
...

[pierre-wehbe]

@badboy Indeed, renaming our local core lib to anything else works...

[mhammond]

There are some places we use core:: where using ::core:: would probably solve this - eg, here

[pierre-wehbe]

@mhammond That was my thought as well, I've unblocked us by renaming our current library, but I bet lots of repos would have a "core" package internal to them, would be nice to prioritize this issue

[badboy]

There are some places we use core:: where using ::core:: would probably solve this - eg, here

Ah, somehow that is the one instance I overlooked. Yes, changing that to ::core should likely fix this issue.

@mhammond That was my thought as well, I've unblocked us by renaming our current library, but I bet lots of repos would have a "core" package internal to them, would be nice to prioritize this issue

I kinda doubt that many people name their crate core. Probably a lot of other crates would use core:: and thus naming an internal crate core has high potential of more breakage. Nonetheless we should of course fix uniffi here.