kaegi / subparse Goto Github PK

This crate fails to build due to a subdependency of vobsub:

Checking image v0.12.4
error[E0004]: non-exhaustive patterns: `PNG`, `JPEG`, `GIF` and 7 more not covered
   --> E:\Program Files\Rust\.cargo\registry\src\github.com-1ecc6299db9ec823\image-0.12.4\./src\dynimage.rs:611:11
    |
611 |       match format {
    |             ^^^^^^ patterns `PNG`, `JPEG`, `GIF` and 7 more not covered
    |
   ::: E:\Program Files\Rust\.cargo\registry\src\github.com-1ecc6299db9ec823\image-0.12.4\./src\image.rs:108:1
    |
108 | / pub enum ImageFormat {
109 | |     /// An Image in PNG Format
110 | |     PNG,
111 | |
...   |
137 | |     HDR,
138 | | }
    | |_- `image::ImageFormat` defined here
    |
    = help: ensure that all possible cases are being handled, possibly by adding
 wildcards or more match arms
    = note: the matched value is of type `image::ImageFormat`

Compiled using
nightly-x86_64-pc-windows-msvc
rustc 1.48.0-nightly (d006f5734 2020-08-28)

The crate vobsub seems abandoned, and an actively maintained fork exist: subtile.

Please consider migrating to use subtile instead of vobsub.

subparse::parse_str has ClonableSubtitleFile as part of its return type, but that type isn't exported in the crate's public interface.

Basically I am trying to define an internal helper function in my code that uses parse_str to return a Box<SubtitleFile>, but I am having issues since ClonableSubtitleFile is private and I can't seem to cast the types properly.

I have a subtitle with this:

857
00:46:28,703 --> 00:46:30,288

erenotgonna supportthat

Obviously this is a problem srt. This crate gives:

thread 'main' panicked at 'parser error: Error { inner: Error { inner: ParseIntError { kind: InvalidDigit }

expected SubRip index line, found 'erenotgonna supportthat'

Which isn't horrible but seems like it could have a more graceful crash, or better yet handle the extra return. My guess is it got this way from someone editing a subtitle and removing [Ruby] (Persons name) w/o removing the return.

Here's a .srt file which both ffmpeg and pysubs2 parse without complaint, which subparse fails on:

1
00:00:06,000 --> 00:00:12,074
text1

2

2
00:11:49,412 --> 00:11:52,858
text2

Both ffmpeg's behavior and pysub2's behavior is to nest the extra line into the previous entry

1
00:00:06,000 --> 00:00:12,074
text1
2

2
00:11:49,412 --> 00:11:52,858
text2

I was working on a python binding for subparse and a file similar to this one triggered an error I wasn't expecting. https://github.com/john-parton/subparsepy