I have set up a rust base project according to the Getting Started page of the rocket-framework:
I added this line to my Cargo.toml: rocket = "0.4.10"
My main.rs:
#![feature(proc_macro_hygiene, decl_macro)]
#[macro_use] extern crate rocket;
#[get("/")]
fn index() -> &'static str {
"Hello, world!"
}
fn main() {
rocket::ignite().mount("/", routes![index]).launch();
}
When I try to run (or cargo build it) I get the following error:
Compiling rocket v0.4.10 error[E0277]: the trait bound `(dyn handler::Handler + 'static): handler::Handler` is not satisfied --> /Users/.../.cargo/registry/src/github.com-1ecc6299db9ec823/rocket-0.4.10/src/rocket.rs:299:41
| 299 | let outcome = route.handler.handle(request, data);
| ^^^^^^ the trait `handler::Handler` is not implemented for `(dyn handler::Handler + 'static)`
For more information about this error, try `rustc --explain E0277`. error: could not compile `rocket` due to previous error
I also tried it with previous versions of the rocket framework, all of them threw the same error.
Of course I'm using the latest nightly version of rust, right before cargo build I entered following commands:
rustup override set nightly
info: using existing install for 'nightly-x86_64-apple-darwin'
info: override toolchain for '/Users/...' set to 'nightly-x86_64-apple-darwin'
nightly-x86_64-apple-darwin unchanged - rustc 1.58.0-nightly (bd41e09da 2021-10-18)
Is there a known issue with the latest rust compiler on MacOS? Is there any other solution I could try?
Related
I'm starting on a command-line tool in Rust, and hitting a wall right from the get-go. I can parse command-line arguments using StructOpt if the Opt struct is defined in main.rs, but since I want to be able to pass the Opt struct into the library code, I'm defining it in its own file so that other parts of the library know what it's all about.
Here's the version of the code that's dumping the fewest errors, although I concede that it's largely cobbled together by trying things suggested by the compiler and some random SO suggestions, so it may be completely wrong.
The build error I'm getting is:
$ cargo run
Compiling basic v0.1.0 (/home/mpalmer/src/action-validator/blobble)
error[E0433]: failed to resolve: maybe a missing crate `structopt`?
--> src/opt.rs:8:5
|
8 | /// Activate debug mode
| ^^^^^^^^^^^^^^^^^^^^^^^ not found in `structopt::clap`
|
help: consider importing this struct
|
3 | use opt::structopt::clap::Arg;
|
For more information about this error, try `rustc --explain E0433`.
error: could not compile `basic` due to previous error
$ cargo --version
cargo 1.56.0 (4ed5d137b 2021-10-04)
$ rustc --version
rustc 1.56.0 (09c42c458 2021-10-18)
(Yes, I have tried adding use opt::structopt::clap::Arg;, just in case, but the error doesn't go away and I get a warning about an unused import -- while still being told to try adding the same use that is unused, which is amusing)
Cargo.toml
[package]
name = "basic"
version = "0.1.0"
authors = ["User"]
[dependencies]
structopt = "0.3"
src/main.rs
extern crate basic;
extern crate structopt;
use basic::Opt;
use structopt::StructOpt;
fn main() {
let opt = Opt::from_args();
println!("{:#?}", opt)
}
src/lib.rs
mod opt;
pub use crate::opt::Opt;
src/opt.ts
extern crate structopt;
use self::structopt::StructOpt;
#[derive(StructOpt, Debug)]
#[structopt(name = "basic")]
pub struct Opt {
/// Activate debug mode
#[structopt(short,long)]
debug: bool,
}
Suggestions gratefully appreciated.
A working version is
Cargo.toml
[package]
name = "basic"
version = "0.1.0"
authors = ["User"]
edition = "2018"
[dependencies]
structopt = "0.3"
lib.rs
#[macro_use] extern crate structopt;
use structopt::StructOpt;
pub mod opt;
opt.rs
#[derive(StructOpt, Debug)]
#[structopt(name = "basic")]
pub struct Opt {
/// Activate debug mode
#[structopt(short,long)]
debug: bool,
}
main.rs
#[macro_use] extern crate structopt;
use structopt::StructOpt;
fn main() {
let opt = basic::opt::Opt::from_args();
println!("{:#?}", opt);
}
You need to declare use structopt::StructOpt because from_args trait must be in the scope.
Trying to compile following rust code to wasm to make it compatible running with existing js. Trying to return hashmaped value from function.
lib.rs
use wasm_bindgen::prelude::*;
use std::collections::HashMap;
#[wasm_bindgen]
pub fn get_transformed_filters()-> HashMap<i32, i32> {
let mut hm = HashMap::new();
for i in 1..9990000 {
hm.insert(i + i, i * i);
}
return hm
}
Console error after running command wasm-pack build
[INFO]: 🎯 Checking for the Wasm target...
[INFO]: 🌀 Compiling to Wasm...
Compiling hello-wasm v0.1.0 (/Users/mfe/ui/rustService/test-wasm)
error[E0277]: the trait bound `HashMap<i32, i32>: IntoWasmAbi` is not satisfied
--> src/lib.rs:15:1
|
15 | #[wasm_bindgen]
| ^^^^^^^^^^^^^^^ the trait `IntoWasmAbi` is not implemented for `HashMap<i32, i32>`
|
= note: required because of the requirements on the impl of `ReturnWasmAbi` for `HashMap<i32, i32>`
= note: this error originates in an attribute macro (in Nightly builds, run with -Z macro-backtrace for more info)
error: aborting due to previous error
For more information about this error, try `rustc --explain E0277`.
error: could not compile `test-wasm`
To learn more, run the command again with --verbose.
Error: Compiling your crate to WebAssembly failed
Caused by: failed to execute `cargo build`: exited with exit code: 101
full command: "cargo" "build" "--lib" "--release" "--target" "wasm32-unknown-unknown"
Is there any way to achieve this ?
So we are currently trying to compile some Rust code that we can then link to some C code. To do this we are using Bindgen to generate an FFI, and then we will use it to call some C functions from Rust.
However, we must first have the crate "libc" as a dependency in the Cargo.toml file of the project. The project we are currently working on demands that we use the crate wide !#[no_std] attribute, as we don't want the entire stdlib of Rust. We only need the core. The libc crate says we can "request" it not be linked to the standard library by putting some options in the Cargo.toml file, namely:
[dependencies]
libc = { version = "0.2", default-features = false }
This is all fine and dandy, but when we try to compile we get the following error message.
Ubuntu:~/nautilus/src/rust/example# cargo build
Compiling example v0.0.0 (/home/me/nautilus/src/rust/example)
error[E0152]: duplicate lang item found: `panic_impl`.
--> src/lib.rs:33:1
|
33 | / pub fn nk_rust_panic(_info: &PanicInfo) -> !
34 | | {
35 | | // should call nk_panic here...
36 | | loop { }
37 | | }
| |_^
|
= note: first defined in crate `std`.
error: aborting due to previous error
For more information about this error, try `rustc --explain E0152`.
error: Could not compile `example`.
To learn more, run the command again with --verbose.
E0152 is the following
A lang item was redefined.
Erroneous code example:
```
#![feature(lang_items)]
#[lang = "arc"]
struct Foo; // error: duplicate lang item found: `arc`
```
Lang items are already implemented in the standard library. Unless you are
writing a free-standing application (e.g. a kernel), you do not need to provide
them yourself.
You can build a free-standing crate by adding `#![no_std]` to the crate
attributes:
```
#![no_std]
```
Our lib.rs file has #![no_std] already in it, but it appears that since libc would normally link against stdlib, that maybe Rust thinks that we cannot have a custom panic handler if we are using libc.
The problem relieves itself when we remove libc from the Cargo.toml file, and remove the extern crate lib from lib.rs.
lib.rs
// no stdlib
#![no_std]
// Give us this feature to override?
#![feature(start)]
#![feature(lang_items)]
// avoid buildins - we want it to use our library
#![no_builtins]
// The following cruft is here to handle Rust->OS dependencies
// currently only one: Rust needs to know how to panic
use core::panic::PanicInfo;
extern crate libc;
#[panic_handler]
#[no_mangle]
pub fn nk_rust_panic(_info: &PanicInfo) -> !
{
// should call nk_panic here... (panic handler of OS)
loop { }
}
Cargo.toml
[package]
name = "example" # this is for core-kernel
version = "0.0.0"
[lib]
crate-type = ["staticlib"]
[dependencies]
libc = { version = "0.2", default-features = false }
[build-dependencies]
bindgen = "0.42.2"
[profile.dev]
panic = "abort" # no stack unwind on rust panic
[profile.release]
panic = "abort" # no stuck unwind on rust panic
So, in sum, does using libc as a dependency make us unable to use our own custom panic handler? Are there any wonky compiler flags we can pass directly to rustc to eliminate this problem?
Compiler is 1.32.0-nightly
Libc version is libc v0.2.44
You are running into a bug in Cargo.
Features are a bit subtle. They can be enabled by any transitive dependency, which is expected behaviour. However, they can even be enabled by transitive build dependencies, which is a bug.
Here is a simple testcase, which still works on the playpen:
use std::num;
use std::str::FromStr;
use std::convert::From;
#[derive(Debug)]
struct Error(String);
impl From<num::ParseFloatError> for Error {
fn from(err: num::ParseFloatError) -> Error {
Error(format!("{}", err))
}
}
fn parse(s: &String) -> Result<f64, Error> {
Ok(try!(<f64 as FromStr>::from_str(&s[..])))
}
fn main() {
println!("{:?}", parse(&"10.01".to_string()));
}
However, after I built the latest rustc from git (now it's rustc 1.1.0-dev (1114fcd94 2015-04-23)), it stopped compiling with following error:
<std macros>:6:1: 6:32 error: the trait `core::convert::From<core::num::ParseFloatError>` is not implemented for the type `Error` [E0277]
<std macros>:6 $ crate:: convert:: From:: from ( err ) ) } } )
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<std macros>:1:1: 6:48 note: in expansion of try!
exp.rs:15:8: 15:48 note: expansion site
error: aborting due to previous error
I'm unable to find out what's wrong. Why is the compiler unable to find my trait implementation?
This looks like it is a bug: std::num::ParseFloatError and <f64 as FromStr>::Err are different types:
the impl of FromStr for f64 is in core, and hence uses a ParseFloatError type defined in that crate, so any uses of FromStr/.parse() will get this type.
std::num defines a new ParseFloatError type, so an import from std::num gets this one.
The impl From<num::ParseFloatError> for Error is using the latter, while <f64 as FromStr>::from_str(...) is returning the former.
I opened #24748 about it. I also opened #24747 about improving the diagnostics to make this easier to debug in future.
One can work around this by insteading implementing the trait for core::num::ParseFloatError. You'll need to load the core crate with extern crate core; and will need some feature gates.
I'm trying to compile the following code, from the Rust book at the Rust official website.
fn takes_slice(slice: &str) {
println!("Got: {}", slice);
}
fn main() {
let s = "Hello".to_string();
takes_slice(&s);
}
At compilation, it throws the following error
/devl/rust/bc_09/src/main.rs:7:17: 7:19 error: mismatched types:
expected &str, found &collections::string::String (expected str,
found struct collections::string::String)
/devl/rust/bc_09/src/main.rs:7 takes_slice(&s);
^~ error: aborting due to previous error Could not compile hello_world.
Here is the Rust version I'm running: rustc 1.0.0-nightly (44a287e6e 2015-01-08 17:03:40 -0800)
That's a really old version of the nightly in Rust terms! Old enough that the &String -> &str coercion isn't available. You just need to upgrade to a newer version.