function register is private

[mitsuhiko]

This happened after a recent upgrade:

/Users/mitsuhiko/.cargo/registry/src/github.com-1ecc6299db9ec823/quasi_macros-0.15.0/src/lib.rs:21:5: 21:28 error: function `register` is private
/Users/mitsuhiko/.cargo/registry/src/github.com-1ecc6299db9ec823/quasi_macros-0.15.0/src/lib.rs:21     quasi_codegen::register(reg);
                                                                                                       ^~~~~~~~~~~~~~~~~~~~~~~
/Users/mitsuhiko/.cargo/registry/src/github.com-1ecc6299db9ec823/quasi_macros-0.15.0/src/lib.rs:21:29: 21:32 error: mismatched types [E0308]
/Users/mitsuhiko/.cargo/registry/src/github.com-1ecc6299db9ec823/quasi_macros-0.15.0/src/lib.rs:21     quasi_codegen::register(reg);
                                                                                                                               ^~~
/Users/mitsuhiko/.cargo/registry/src/github.com-1ecc6299db9ec823/quasi_macros-0.15.0/src/lib.rs:21:29: 21:32 help: run `rustc --explain E0308` to see a detailed explanation
/Users/mitsuhiko/.cargo/registry/src/github.com-1ecc6299db9ec823/quasi_macros-0.15.0/src/lib.rs:21:29: 21:32 note: expected type `&mut syntex::Registry`
/Users/mitsuhiko/.cargo/registry/src/github.com-1ecc6299db9ec823/quasi_macros-0.15.0/src/lib.rs:21:29: 21:32 note:    found type `&mut rustc_plugin::Registry<'_>`

[andete]

try replacing this:

let mut registry = syntex::Registry::new();
serde_codegen::register(&mut registry);
registry.expand("", &src, &dst).unwrap();

with this in your build.rs build script:

serde_codegen::expand(&src, &dst).unwrap();

[mitsuhiko]

@andete i already do this.

[mitsuhiko]

This is the lib file from quasi_macros 0.15 in question:

#![feature(plugin_registrar, unboxed_closures, rustc_private)]
#![cfg_attr(feature = "unstable-testing", feature(plugin))]
#![cfg_attr(feature = "unstable-testing", plugin(clippy))]

extern crate quasi_codegen;
extern crate rustc_plugin;

#[plugin_registrar]
#[doc(hidden)]
pub fn plugin_registrar(reg: &mut rustc_plugin::Registry) {
    quasi_codegen::register(reg);
}

[andete]

I think it ends up calling the wrong "register" function in quasi_codegen, I wonder if there is a typo in some of the feature stuff that seems to be used for conditional compilation.

[mitsuhiko]

I wonder if this happens if you have different libraries that all want to use quasi and some use codegen and some do not.

[andete]

That could very well be it.

[dtolnay]

I wonder if this happens if you have different libraries that all want to use quasi and some use codegen and some do not.

I bet it's this. You can try using cargo tree to find the transitive dependencies on quasi and see whether there is a mix of syntex and plugin. If you share the crate that is failing to compile, I can help debug.

[mitsuhiko]

Does this mean mixing of different quasi modes is not supported?

[dtolnay]

AFAIK Cargo does not support multiple dependencies on the same version with different features.

[mitsuhiko]

So it seems to be caused by different settings. If I force all crates to use codegen it works. I wonder why this was not an issue before though :-/

[andete]

I have a main library, A, that uses serde_json. A uses B, which also uses serde_json.
This is how I got my build to work:

1. also adjusted B to have the default or nightly feature as documented at the serde page. (A was already like that, B wasn't)
2. modified A to have features like this:

[features]
default = ["serde_codegen", "b/default"]
nightly = ["serde_macros", "b/nightly"]

3. and a dependency for B like this:

b = { git = "...", default-features = false }

3. did a cargo clean (cargo doesn't seem to pick up changes like this)
4. did a cargo build --features nightly --no-default-features
5. did a plain cargo build; still works as well

[mitsuhiko]

The problem is that this requires all libraries to agree on how to use serde some of which might be out of my control.

[andete]

Yes, it would be nicer if it could somehow play nice together.

[dariusc93]

Is there any resolution for this issue?

[dtolnay]

serde-rs/serde#543 is tracking a resolution of this issue across the ecosystem.

[k0pernicus]

Using rustc 1.14.0-nightly (cae6ab1c4 2016-11-05) and cargo 0.13.0-nightly (9c47815 2016-11-04), I can't compile quasi_macros, due to:

Running `/Users/antonin/Documents/dev/rust/github-api-rs/target/debug/build/serde_codegen-a5d79e3092b1898e/build-script-build`
error: function `register` is private
  --> /Users/antonin/.cargo/registry/src/github.com-1ecc6299db9ec823/quasi_macros-0.20.0/src/lib.rs:21:5
   |
21 |     quasi_codegen::register(reg);
   |     ^^^^^^^^^^^^^^^^^^^^^^^

error[E0308]: mismatched types
  --> /Users/antonin/.cargo/registry/src/github.com-1ecc6299db9ec823/quasi_macros-0.20.0/src/lib.rs:21:29
   |
21 |     quasi_codegen::register(reg);
   |                             ^^^ expected struct `syntex::Registry`, found struct `rustc_plugin::Registry`
   |
   = note: expected type `&mut syntex::Registry`
   = note:    found type `&mut rustc_plugin::Registry<'_>`

error: aborting due to previous error

Build failed, waiting for other jobs to finish...
error: Could not compile `quasi_macros`.

[k0pernicus]

For my problem, that's weird because the compiler tells me that is the 0.20.0 version of quasi_macros that canno't be compiled, and not the latest (0.25.1)...

This is a list of my dependencies:

hyper = "0.9"
serde = "0.8"
serde_derive = "0.8"
serde_macros = "0.8"
serde_json = "0.8"

A quick search in my Cargo.lock file shows that serde_codegen required 0.20.0 version of quasi_macros:

[[package]]
name = "serde_codegen"
version = "0.8.9"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
 "aster 0.27.0 (registry+https://github.com/rust-lang/crates.io-index)",
 "quasi 0.20.1 (registry+https://github.com/rust-lang/crates.io-index)",
 "quasi_codegen 0.20.0 (registry+https://github.com/rust-lang/crates.io-index)",
 "quasi_macros 0.20.0 (registry+https://github.com/rust-lang/crates.io-index)",
 "serde_codegen_internals 0.8.9 (registry+https://github.com/rust-lang/crates.io-index)",
 "syntex 0.44.0 (registry+https://github.com/rust-lang/crates.io-index)",
 "syntex_syntax 0.44.1 (registry+https://github.com/rust-lang/crates.io-index)",
]

I tried a lot of time to clean and build again my project but I still got this problem...

[dtolnay]

@k0pernicus serde_macros is not supported any more, which is why the last release (6 weeks old at this point) is pulling in an old quasi. Can you see whether the problem goes away when using serde_derive instead of serde_macros? See this forum topic for the relevant announcement.

[k0pernicus]

Ok, it's seems ok now, but I used #![plugin(serde_macros)] to use some features like #[serde(skip_serializing_if="Option::is_none")].
Is there any other plugin to use serde macros?

[k0pernicus]

Update: I found a solution using #![feature(custom_derive, custom_attribute)].
Now, I need to satisfy Deserialize...

Thanks a lot @dtolnay

[dtolnay]

@k0pernicus

Is there any other plugin to use serde macros?

Yes, serde_derive is that plugin. Look at the forum topic I linked to or serde docs for how to set it up. You shouldn't need #![feature(custom_derive, custom_attribute)].

[colindjk]

Hey currently I tried to fix this issue by removing serde_derive from my Cargo.toml, and I now have this -

[dependencies]
serde = "0.8.*"
serde_xml = "0.8.*"
serde_derive = "0.8.*"

futures = "0.1"
tokio-core = "0.1"

env_logger = "0.3"

Which fails to compile with this - (When compiling serde_derive)
4 | extern crate rustc_macro;
| ^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate

I've been tearing my hair our trying to figure this out :s.

[dtolnay]

@colindjk you need to run cargo update to pick up a newer version of serde_derive. You should be seeing 0.8.17 which no longer uses rustc_macro. Keep in mind that serde_derive relies on unstable Rust features so we do our best to keep the latest version working but it is impossible for us to support old versions.

[colindjk]

@dtolnay Welp actually just fixed it earlier by removing my Cargo.lock... it's been a long week XD. I suppose I'll leave it there in case someone makes a simple mistake like that.

Thanks.