charlesvdv
commented
5 years ago I am not sure which ones were there in 3.0, and which were not
To be totally honest, I don't know either since it's been a while since I haven't touched this project or the nom library.
Because of the above two reasons, I decided that the whole parser could only reason on CompleteByteSlices. It makes sense for BibTeX, I think, since those are typically "small" files (some kB).
This seems completely reasonable to me.
Anyhow, all tests pass.
Yep! I will into this CI failure so this doesn't happen anymore.
feel free to hit me up in Brussels/at VUB :-)
I think we already seen each others at the first Rust meetup? Is it possible?
Anyway, thanks for the PR! :smile:
rubdos
Holy crap that was heavy. This is the first PR in the series to support #1; I first want to support
nom4.0 before moving on.Most time was taken by dealing with
Incomplete.nom4.0 made Incomplete way more strict. A bunch of things happen there. I am not sure which ones were there in 3.0, and which were not, but I'll drop them here:ws!()macro cannot complete on unterminated slices, since it assumes that white space may follow in the stream.no_type_commentused a custom parsing function that searched for the\0byte. I am not sure, but I think this was a C-ism? I moved fromalt!(take_until("@") | take_until_end)to simplyis_not("@"). This does mean this never terminates on unterminated slices either.Because of the above two reasons, I decided that the whole parser could only reason on
CompleteByteSlices. It makes sense for BibTeX, I think, since those are typically "small" files (some kB).Making everything
CompleteByteSlice's takes a tin of code, especially in tests, where almost everything needs to get wrapped in that struct. It's a bit sad, but it's how it works for now...Anyhow, all tests pass. Please take a look at my reasoning, and feel free to hit me up in Brussels/at VUB :-)