Parse from `R: Read` instead of byte slice

[eira-fransham]

Even though this parser is streaming, it's currently not possible to actually have it operate on a stream. The API requires a &[u8]. This isn't really necessary though, most of the API could remain identical while supporting any input type R where R: Read. I tried to implement this myself but this codebase is so huge and has so much duplicated code that I gave up, since it's not immediately necessary for my use-case.

[yurydelendik]

Yes, that is the change that needs to be made. I need to investigate the performance impact first (and was hoping bytecodealliance/wasmparser#8 is addressed first)

[eira-fransham]

It's possible to use specialisation to allow byte slices/vectors to continue to slice into the input for references (such as names) while other Read impls collect into a vector, which should eliminate the only possible performance impact.

[Robbepop]

I wonder what it would take to actually implement this initially for this crate. It is hard for me to estimate the work that needs to be done for this. However, this is really important to make wasmparser support streaming parsing applications that are actually out there in the wild. ;)

I guess for things like the BrTable that needs double-parsing this change to T: Read might be tricky but in general it should be implementable and shouldn't have significant performance impacts if we buffer our reads from the sources correctly.

@yurydelendik What do you think about this?

[alexcrichton]

I've proposed a redesign of this crate which would make it possible to implement this feature at #40, and if others have feedback on that it'd be very much appreciated!

[Robbepop]

Since #40 has been merged, what is left to implement this?

From what I understood the new APIs actually implement this issue's proposal and thus the issue can be closed, right?
The only missing piece is the validate root level API but I doubt that we can adjust it to T: Read or similar since it is mainly an API targeting simple use cases.

[alexcrichton]

Ah yes indeed I don't think there's a ton left to do on this. The docs have an example of parsing from T: Read, and perhaps that's good enough?

[Robbepop]

Discoverability of the docs could be better but I think the docs together with the updated codebase renders this issue pretty much implemented. So issue can be closed imo.
While the API does not really follow the proposal of this issue the new codebase allows for the same use case that this issue originally tried to cover.