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

string_lit_as_bytes doesn't work correctly #1402

Open
farodin91 opened this issue Dec 23, 2016 · 4 comments
Open

string_lit_as_bytes doesn't work correctly #1402

farodin91 opened this issue Dec 23, 2016 · 4 comments
Labels
C-bug Category: Clippy is not doing the correct thing E-medium Call for participation: Medium difficulty level problem and requires some initial experience. I-suggestion-causes-error Issue: The suggestions provided by this Lint cause an ICE/error when applied

Comments

@farodin91
Copy link

I'm not shure why this not work correct.
"key".as_bytes().to_owned() => b"key".to_owned() for type Vec<u8>

@clarfonthey
Copy link
Contributor

clarfonthey commented Dec 24, 2016

It's because b"key" is interpreted as [u8; 3] when to_owned is expecting [u8]. This is something that should be fixed on the compiler end, but for now, it's an error in the lint.

@sinkuu
Copy link
Contributor

sinkuu commented Dec 24, 2016

This doesn't seem to be a compiler issue. to_owned clones things that can be cloned (impl<T> ToOwned for T where T: Clone { type Owned = T; }), and b"key" is a [u8; 3] which is Clone.

Try using [T]::to_vec; b"key".to_vec() returns Vec<u8>.

@farodin91
Copy link
Author

@sinkuu .to_vec() works perfect for me.
Thank you.

@dtolnay
Copy link
Member

dtolnay commented Oct 5, 2020

Just sharing a concrete repro for "doesn't work":

fn f(_: Vec<u8>) {}

fn main() {
    f("...".as_bytes().to_owned());
}

Suggestion by clippy:

warning: calling `as_bytes()` on a string literal
  --> src/main.rs:4:7
  |
4 |     f("...".as_bytes().to_owned());
  |       ^^^^^^^^^^^^^^^^ help: consider using a byte string literal instead: `b"..."`
  |
  = note: `#[warn(clippy::string_lit_as_bytes)]` on by default
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#string_lit_as_bytes

So we change:

-     f("...".as_bytes().to_owned());
+     f(b"...".to_owned());

Resulting type error:

error[E0308]: mismatched types
  --> src/main.rs:4:7
  |
4 |     f(b"...".to_owned());
  |       ^^^^^^^^^^^^^^^^^
  |       |
  |       expected struct `Vec`, found array `[u8; 3]`
  |       help: try using a conversion method: `b"...".to_owned().to_vec()`
  |
  = note: expected struct `Vec<u8>`
              found array `[u8; 3]`

bors added a commit that referenced this issue Oct 8, 2020
Downgrade string_lit_as_bytes to nursery

Between #1402 (regarding `to_owned`) and #4494 (regarding `impl Read`), as well as other confusion I've seen hit in my work codebase involving string_lit_as_bytes (`"...".as_bytes().into()`), I don't think this lint is at a quality to be enabled by default.

I would consider re-enabling this lint after it is updated to understand when the surrounding type information is sufficient to unsize `b"..."` to &\[u8\] without causing a type error.

As currently implemented, this lint is pushing people to write `&b"_"[..]` which is not an improvement over `"_".as_bytes()` as far as I am concerned.

---

changelog: Remove string_lit_as_bytes from default set of enabled lints
@camsteffen camsteffen added C-bug Category: Clippy is not doing the correct thing I-suggestion-causes-error Issue: The suggestions provided by this Lint cause an ICE/error when applied E-medium Call for participation: Medium difficulty level problem and requires some initial experience. labels Nov 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: Clippy is not doing the correct thing E-medium Call for participation: Medium difficulty level problem and requires some initial experience. I-suggestion-causes-error Issue: The suggestions provided by this Lint cause an ICE/error when applied
Projects
None yet
Development

No branches or pull requests

5 participants