rust: regarding "avoid using extern crate"

[bobbens]

Describe the bug
The meson documentation at https://mesonbuild.com/Rust.html says to Avoid using extern crate with Rust, and that:

If your crate dependencies are properly expressed in Meson, there should be no need for extern crate statements in your Rust code.

I would like clarification on this last point as I have not been able to get a trivial example to work without the extern crate statement.

To Reproduce
Full code to reproduce is at crate-fail.tar.gz (it will succeed by default as it has extern crate).

Files are below:

1. meson.build

project('crate-fail', 'rust', version : '0.1' )
exe = executable('crate-fail', 'main.rs', dependencies: dependency('colour-2-rs') )

2. main.rs

extern crate colour;
use colour::*;

fn main () {
    green_ln!("Hello World!");
}

3. subprojects/colour-rs.wrap

[wrap-file]
method = cargo
directory = colour-2.1.0
source_url = https://crates.io/api/v1/crates/colour/2.1.0/download
source_filename = colour-2.1.0.tar.gz
source_hash = b536eebcabe54980476d120a182f7da2268fe02d22575cca99cee5fdda178280
[provide]
dependency_names = colour-2-rs

The dependency is clearly defined in meson where the executable depends on the colour-rs subproject wrap, that is compiled from Rust. However, despite the documentation clearly stating extern crate is bad, without the statement, it does not seem to compile and fails with the following error:

$ meson compile
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /usr/bin/ninja
[1/1] Compiling Rust source ../main.rs
FAILED: crate-fail
rustc -C linker=cc --color=always -C debug-assertions=yes -C overflow-checks=no --crate-type bin -g --crate-name crate_fail --emit dep-info=crate-fail.d --emit link=crate-fail --out-dir crate-fail.p -C metadata=crate-fail@exe --extern colour=subprojects/colour-2.1.0/libcolour.rlib -Lsubprojects/colour-2.1.0 ../main.rs
error[E0432]: unresolved import `colour`
 --> ../main.rs:1:5
  |
1 | use colour::*;
  |     ^^^^^^ maybe a missing crate `colour`?
  |
  = help: consider adding `extern crate colour` to use the `colour` crate

error: cannot find macro `green_ln` in this scope
 --> ../main.rs:4:5
  |
4 |     green_ln!("Hello World!");
  |     ^^^^^^^^

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0432`.
ninja: build stopped: subcommand failed.

Expected behavior
I would expect it to either compile without the extern crate or for the documentation to mention extern crate being necessary.

system parameters

• native build
• arch linux
• Python 3.12.6
• meson 1.5.2
• ninja 1.12.1

[dcbaker]

What rust standard (edition) are you using? Rust has the opposite approach of most C compilers, if you don't set a standard/edition you get the oldest one, unlike C where you get the newest one. IIRC this got changed in a later edition, so adding project(..., default_options : ['rust_std=2021']) (and meson configure $builddir -Drust_std=2021 if you want to reuse your configured build directory) should resolve this.

[dcbaker]

If that does I'll send a PR to update the documentation

[bobbens]

What rust standard (edition) are you using? Rust has the opposite approach of most C compilers, if you don't set a standard/edition you get the oldest one, unlike C where you get the newest one. IIRC this got changed in a later edition, so adding project(..., default_options : ['rust_std=2021']) (and meson configure $builddir -Drust_std=2021 if you want to reuse your configured build directory) should resolve this.

Thanks for the prompt reply. Honestly, I have no idea what I'm doing (mainly just seeing feasibility of porting large C project to rust over time), however, my rust should be fairly modern giving I'm running arch linux. rustc --version gives rustc 1.81.0 (eeb90cda1 2024-09-04) (Arch Linux rust 1:1.81.0-1).

That said, it does seem like the fixes you mention ( project(..., default_options : ['rust_std=2021']) (and meson configure $builddir -Drust_std=2021) does seem to fix the issue. Maybe these options should be default (and documentation updated)?

[dcbaker]

Changing the default would have to be a Meson 2.0 thing, because that would be a user visible change (and would be different than what Cargo does). We should update the documentation though, since that clearly matters

[bobbens]

Changing the default would have to be a Meson 2.0 thing, because that would be a user visible change (and would be different than what Cargo does). We should update the documentation though, since that clearly matters

Thanks for the update!

On my system cargo new adds edition = "2021", so having 2021 as default does seem like it would be the same as Cargo, is it not? How does meson choose what edition to use? It should probably be mentioned in the documentation that it defaults to something different than cargo if that is the case.

[dcbaker]

Right, but that's like meson init setting the edition. I'm totally cool with changing meson init (patch welcome), but Meson matches what Cargo does in that if you don't set edition = ... then you get 2015, Meson matches that behavior, if you don't set rust_std=... you get 2015