Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiler says string is not it's own type #14089

Closed
RichardlL opened this issue May 10, 2014 · 2 comments
Closed

Compiler says string is not it's own type #14089

RichardlL opened this issue May 10, 2014 · 2 comments

Comments

@RichardlL
Copy link

I have the code
let mut vari = "";
...
vari = vari + str::from_char(chr);

(I cant used an owned string, because i have a large pattern match, and it wont accept ~"String to match", as it interprets it as a a owned static string instead of a owned string, and it wont accept "String to match".to_owned() either)

But back to the problem, it says vari doesnt have an appropriate type for vari?

src/main.rs:161:11: 161:37 error: mismatched types: expected &'static str but found ~str (str storage differs: expected &'static but found ~)

src/main.rs:161             vari = vari + str::from_char(chr); 
                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous 

and i cant use += as that results in
binary assignment operation += cannot be applied to type &static str

Im not sure if this is a bug, but it's confusing me

@Ryman
Copy link
Contributor

Ryman commented May 10, 2014

Rust won't allow manipulation of static strings, you'll want to use the StrBuf type. http://static.rust-lang.org/doc/master/std/strbuf/struct.StrBuf.html

You can match on vari.as_slice(), try the following:

let mut vari = StrBuf::new();
vari.push_char('c');

match vari.as_slice() {
    "c" => println!("Got a `c`"),
    _ => println!("Not a `c`")
}

@alexcrichton
Copy link
Member

The error message is correct in that + returns ~str (in this case) instead of &'static str (the type of a string literal). @Ryman has some good suggestions about how you can continue to pattern match even with owned strings.

Closing as working as intended.

bors added a commit to rust-lang-ci/rust that referenced this issue Feb 13, 2023
Unify language configuration folding markers with server behaviour

Fixes rust-lang#14089.
flip1995 pushed a commit to flip1995/rust that referenced this issue Feb 20, 2025
Checks for `Read::bytes()` on an unbuffered Read type.
The default implementation calls `read` for each byte, which can be very
inefficient for data that’s not in memory, such as `File`.

Considerations which I'd like to have feedback on:
* Currently this lint triggers when `.bytes()` is called on any type
that implements `std::io::Read` but not `std::io::BufRead`. This is
quite aggressive and in and may result in false positives. Alternatives:
* Only trigger on concrete types, not generic types. This does mean that
cases where a function is generic over a `R: Read` and calls `.bytes()`
are not caught by the lint, which could be quite a nasty case of this
bug.
  * Only trigger on an allowlist of stdlib types
* Compromise: Is it possible to make this lint `pedantic` on types that
are not on a allowlist?
* Theoretically, a trait implementation of `Read` could override
`.bytes()` with an efficient implementation. I'm not sure how to add
this check to the lint, and I can't find any cases of this being done in
practice.
* I don't think an automatic fix for this lint is possible, but I'd love
to be proven wrong
* This is my first time contributing to clippy, please let me know if I
did anything wrong

Fixes rust-lang#14087
```
changelog: [`unbuffered_bytes`]: new lint
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants