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`: ```rust 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: ```idl 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.