rust no longer accepts comparison between byte and i8 in event.rs, expects u8

[makoConstruct]

just here and a couple lines down in the case for TextInput as well. thx.

(hopefully irrelevant but I'll mention it just in case: I'm compiling for arm, with a very recently compiled rustc)

[makoConstruct]

o_o Uhh.. apparently it was relevant. When I compile for x86_64 it refuses to accept a u8 and expects an i8. I guess I'll file a bug upstream, then?

[MagaTailor]

rust-lang/rust#29867

[makoConstruct]

true

[MagaTailor]

The solution is still missing though.

[makoConstruct]

Is updating your rustc to the most recent version not an adequate solution? Another workaround is simply adding a conversion on the left side in the expression on the two offending lines:

                            .take_while(|&b| (*b) as u8 != 0u8)

[MagaTailor]

No, it's actually the problem (coupled with the libc crate update). The way it's looking right now crate authors will have been forced to fix this breakage at crate level.

I wanted to open an issue for sdl2 but found it'd already been done (more or less). Until a new crate gets published it should definitely stay open.

[MagaTailor]

We're talking about this kind of problem in general:

 >     Compiling sdl2 v0.8.0

+---- 0.8.0/src/sdl2/clipboard.rs : 34 ----+
      =====>  error: mismatched types:

           >   expected `*const i8`,
           >      found `*const u8`
           >  (expected i8,
           >      found u8) [E0308]
 34 |>              let result = ll::SDL_SetClipboardText(text.as_ptr());
                                                                                                                        ^~~~~~~~~~~~~


+---- 0.8.0/src/sdl2/clipboard.rs : 34 ----+
      =====>  help: run `rustc --explain E0308` to see a detailed
           >        explanation


+---- 0.8.0/src/sdl2/clipboard.rs : 51 ----+
      =====>  error: mismatched types:

           >   expected `*const u8`,
           >      found `*const i8`
           >  (expected u8,
           >      found i8) [E0308]
 51 |>                  Ok(String::from_utf8_lossy(CStr::from_ptr(buf).to_bytes()).into_owned())
                                                                                                                                ^~~


+---- 0.8.0/src/sdl2/clipboard.rs : 51 ----+
      =====>  help: run `rustc --explain E0308` to see a detailed
           >        explanation


+---- 0.8.0/src/sdl2/event.rs : 940 ----+
      =====>  error: mismatched types:

           >   expected `*const u8`,
           >      found `*const i8`
           >  (expected u8,
           >      found i8) [E0308]
 940 |>                  let buf = CStr::from_ptr(event.file).to_bytes();
                                                                                                                ^~~~~~~~~~


+---- 0.8.0/src/sdl2/event.rs : 940 ----+
      =====>  help: run `rustc --explain E0308` to see a detailed
           >        explanation


+---- 0.8.0/src/sdl2/filesystem.rs : 11 ----+
      =====>  error: mismatched types:

           >   expected `*const u8`,
           >      found `*const i8`
           >  (expected u8,
           >      found i8) [E0308]
 11 |>          String::from_utf8_lossy(CStr::from_ptr(buf).to_bytes()).to_string()
                                                                                                                     ^~~

and so on.

[makoConstruct]

Ah, apologies for closing it. It's difficult to imagine why this particular aspect of the problem should be left as it is.

[AngryLawyer]

I'm a touch confused - is this problem still extant?

[MagaTailor]

The big breakage affecting arm linux and android is still there - have a look at the list of affected crates (found so far) at the bottom of rust-lang/rust#29867

The OP's issue may have been fixed by updating libstd but not the sdl2 crate itself.

[AngryLawyer]

Cool. I'll take a pop at fixing this at lunch.

[AngryLawyer]

Okay @petevine and @makoConstruct, I've had a crack at fixing it. It compiles fine on my cross-compiler, but I've not got anything to test it beyond that point.

#472

Does this work for you?