I have the following code block and it works as intended with no problem:
fn literal_taker(literals_slice: &[&str]){
println!("{:?}",literals_slice);
}
fn string_taker(string_value: String){
literal_taker(&[&string_value]);
}
fn main() {
let string_value = String::from("Hello");
string_taker(string_value);
}
Here, I pass the reference of String as a slice and it is compiling with no error and no clippy issue.
But the problem is, It is shown as warning in Clion Rust plugin:
Is it a bug of an plugin or am I doing something bad practice in Rust?
Playground
CLion Rust Plugin Version: 0.2.0.2106-182
The code does compile as written, as the playground clearly demonstrates. Therefore it is a bug in the IDEA Rust Plugin.
Unlike most other Rust plugins that use the Rust Language Server, which uses code from the compiler, and therefore generally provides diagnostics consistent with what the compiler will, IntelliJ IDEA has its own validator, which might get things wrong.
Related
Recently, I started to learn rust. I'm currently at section 7.4 (bringing paths into scope). Tried hard, but I can't understand the purpose of self::some_sort_of_identifier in rust. Would you please explain what is the difference between use self::module_name::function_name and use module_name::function_name? I tried both and they both worked as expected in the example below:
mod my_mod {
pub fn func() {
print!("I'm here!");
}
}
use my_mod::func;
fn main() {
func();
}
Running this program, as expected, I can see this statement printed into the terminal:
I'm here
And this program here gives me exactly the same results and the rust compiler doesn't complain about anything:
mod my_mod {
pub fn func() {
print!("I'm here!");
}
}
use self::my_mod::func;
fn main() {
func();
}
So, is self:: useless in rust? Why should I even use self::my_mod::my_function(); when I can directly call it like so: my_mod::my_function();.
Are there any cases in which they might defer?
For your use-case, it's mainly a relict from the 2015 rust edition.
In this edition the following code would not compile:
use my_mod::func;
mod my_mod {
use my_mod2::func2;
pub fn func() {
func2();
}
mod my_mod2 {
pub fn func2() {
print!("I'm here!");
}
}
}
fn main() {
func();
}
The compiler complains:
error[E0432]: unresolved import my_mod2
--> src\main.rs:4:9
|
| use my_mod2::func2;
| ^^^^^^^ help: a similar path exists: self::my_mod2
Why did it change? You can see the note about the path and module system changes here.
Rust 2018 simplifies and unifies path handling compared to Rust 2015. In Rust
2015, paths work differently in use declarations than they do
elsewhere. In particular, paths in use declarations would always start
from the crate root, while paths in other code implicitly started from
the current scope. Those differences didn't have any effect in the
top-level module, which meant that everything would seem
straightforward until working on a project large enough to have
submodules.
In Rust 2018, paths in use declarations and in other code work the
same way, both in the top-level module and in any submodule. You can
use a relative path from the current scope, a path starting from an
external crate name, or a path starting with crate, super, or self.
The blog post Anchored and Uniform Paths from the language team also underlines this
The uniformity is a really big advantage, and the specific feature we’re changing -
no longer having to use self:: - is something I know is a big
stumbling block for new users and a big annoyance for advanced users
(I’m always having to edit and recompile because I tried to import
from a submodule without using self).
The keyword itself however is still useful in use statments to refer to the current module in the path itself. Like
use std::io::{self, Read};
being the same as
use std::io;
use std::io::Read;
How do I use from_str ? I have the snippet
let base: u32 = from_str::<u32>(&var)
and get the error
Error: unresolved name from_str
So I googled this error and found this, so I tried adding the following
use std::u32;
use std::from_str::FromStr
But now I get
Error: unresolved import `std::from_str::FromStr` could not from `from_str` in `std`
According to this github issue, I need to include this yet rust can't find it. What's going on? Here's a super simple program which gives me those errors
use std::u32;
use std::from_str::FromStr;
fn main() {
let my_str = "String".to_string();
let base: u32 = from_str(&my_str);
}
This is such a trivial issue and yet these resources are only showing me how to get more errors.
Use the docs to search for from_str. They show that the FromStr trait is in std::str now, not std::from_str. (April 2014 is a long time ago in Rust terms, being well before Rust 1.0.0.)
FromStr should not be used directly in general anyway; you should use str.parse method instead: my_str.parse::<u32>(). Remember that it returns a Result, because the string might just not contain a number.
With today's Rust nightly the following code doesn't compile anymore:
#[derive(Show)]
enum S {
A,
B
}
fn main() {
println!("{}", S::A);
}
Instead it gives me the following error message:
error: the trait `core::fmt::String` is not implemented for the type `S`
Is there a way to get the old behaviour? Surely it can't be required to implement this by hand for each type.
The old Show trait was split into Display and Debug.
Display is designed for user-facing output, and uses the blank/default format specifier (e.g. {}, {:.10} {foo:} are all using Display)
Debug is designed for debugging/internal output and uses the ? format specifier (e.g. {:?}, {:.10?}, {foo:?} are all using Debug)
Hence, to use the implementation created by #[derive(Debug)] one should write println!("{:?}", ...), instead of the old println!("{}", ...).
Only Debug can be #[derive]d since output like Foo { x: 1, y: 2 } is unlikely to be the correct user-facing output, for most situations (I'm sure it is for some, but then the programmer can write the implementation of Display to do that themselves, or even call directly into the #[derive]d Debug implementation).
This was originally described in RFC 504 and there is ongoing discussion in RFC 565, making the guidelines stated above more concrete.
The answer is to use {:?} instead of {} in format!.
Given a situation like this one :
trait Basic {
// Some functions
}
trait Derived : Basic {
// some other functions
}
fn do_someting<T : Basic>(target: &mut T) {
// do stuff
}
Is it possible to have the do_something function behave differently depending on whether target implements the trait Derived or not (the information being known at compilation time) ?
I guess something similar could be achieved in C++ using template specialization, but I don't see a Rust equivalent.
AFAIK this is not currently possible. Defining fn do_something<T : Derived> alongside your existing function leads to compilation error:
error: duplicate definition of value `do_someting`
because both versions can be used for Basic.
There are some proposals to allow explicit bounds like <T: Basic + !Derived> that will allow you to resolve this conflict.
But I personally hope that impl overloading/specialization will be possible some day after 1.0 version is released.
I have been using 0.10 and recently setup a build of nightly to experiment with Box and friends.
Now I have code for 0.10 using ~str and code for pre0.11 using String because of to_owned being obsolete. I thought I could do this:
#[cfg(rust_version = "0.10")]
fn my_old_func() -> Option<~str> {
}
#[cfg(not(rust_version = "0.10")]
fn my_old_func() -> Option<String> {
}
And pass --cfg rust_version:0.11 during compilation. But the compiler still chokes on the now removed ~ operator. Is there a way to have code that works under both 0.10 and the as yet unreleased 0.11 using conditional compilation or some other mechanism?
I guess I could fall back to using cpp and #ifdef but that seems like stepping out of the Rust mindset.
No, there is nothing you can do about this.
Our typical recommendation is not to use 0.10 but to stick with nightlies.