Existing code broken by the 1.90 release. Bug?

help
1

Hello!

I have some existing code which has been broken by the 1.90 release. The code below, on playground, fails to compile with 1.90, but succeeded without as much as a warning on 1.89.

Is this a bug? I don't understand why the trait can't resolve as I expect it to, but I haven't dug too deeply. However all my builds are broken now, yikes!

use std::ffi::CString;

fn main() {
    assert_eq!(CString::from(c"foo"), c"foo".into());
}

(Playground)

Errors:

   Compiling playground v0.0.1 (/playground)
error[E0283]: type annotations needed
 --> src/main.rs:4:46
  |
4 |     assert_eq!(CString::from(c"foo"), c"foo".into());
  |                                              ^^^^
  |
  = note: cannot satisfy `_: From<&CStr>`
  = note: required for `&CStr` to implement `Into<_>`
help: try using a fully qualified path to specify the expected types
  |
4 -     assert_eq!(CString::from(c"foo"), c"foo".into());
4 +     assert_eq!(CString::from(c"foo"), <&CStr as Into<T>>::into(c"foo"));
  |

For more information about this error, try `rustc --explain E0283`.
error: could not compile `playground` (bin "playground") due to 1 previous error
1 Like
2

No, this is not a bug. It's expected behavior as there are now multiple trait impls that are possible applicable.

3

It's a case like this, where there used to be only one implementation candidate that would work for the equality testing, and now there are multiple. Here's an earlier report.

4

Thanks! That does explain it. I guess that's always a risk when using something as vague as into(). Much appreciated.

5

On the upside, once you're comfortable with requiring a compiler at version 1.90 or newer, you can just

assert_eq!(some_preexisting_cstring_i_assume, c"foo");

though perhaps for now (for the sake of older compilers) you would prefer to

assert_eq!(&*some_preexisting_cstring_i_assume, c"foo");
2 Likes
6

I have found that those new to rust (especially coming from C) are more comfortable seeing the more-explicit some_cstring.as_c_str(), but it all amounts to the same thing :slight_smile: Thanks again for your help.

7

Do these comparisons take place by comparing them as byte strings by any chance? If not, I'm confused how that could possibly work, as C-strings don't have to be valid UTF-8.

8

Yes.

There are no UTF-8 restricted types in the example.

&* on a CString yields a &CStr and c"..." is a &CStr too.

2 Likes
9

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.