These are chat archives for rust-lang/rust

May 2019
May 17 05:48
Why is ?Sized needed as a special trait at all? When the compiler tries to „instantiate“ a generic method it certainly knows whether the concrete type used is sized or not. And if not, it simply could check that it is only taken by reference/pointer.
May 17 11:37
Hi everyone, I'm new to rust and I need some help involving macros
I'm trying to write a program that uses nom to parse WAV files
for now I have only one file and I have code to parse a generic chunk (id, length, data), I'm getting a really weird compilation error and I can't understand why
this is what I got so far:
extern crate nom;
use nom::{
    bytes::complete::{tag, take_while_m_n, take},
use std::io::{self,Read,Write};
use byteorder::{ByteOrder, LE};

pub struct Chunk {
    id: tag,
    data: data,

fn wav_parser(){
    let chunk_size = LE::read_u32;
    let chunk_id = tag!("RIFF");
    let chunk_format = tag!("WAVE");

    let sub_chunk_size = LE::read_u32;
    let sub_chunk_id = take!(4);
    let sub_chunk = do_parse!( id: chunk_id >>
                               size: chunk_size >>
                               data: take!(size) >>
                               // (Chunk { id: id, data: data }) );
                               ( id,data ) );
    let wav_format = tuple!(chunk_size, chunk_id, chunk_format, sub_chunk, sub_chunk);
    match wav_format {
        Ok((next, wav_parsed)) => wav_parsed,
        Err(e) => eprintln!("{:?}", e),

fn main() {
May 17 11:43
the error I'm getting is:
   Compiling wav-drop-sample v0.1.0 (/home/nivp/my-gits/wav-drop-sample)
error: expected expression, found `,`
  --> src/
27 |                                data: take!(size) >>
   |                                                    ^ expected expression

error: aborting due to previous error
everything looks fine to me, there is an expression exactly there... not just that, the do_parse bit is taken straight from the nom documentation with some few minor (mostly name) changes
Denis Lisov
May 17 12:20
What do you expect the fn wav_parser() to parse if it does not take any arguments? :-)
May 17 14:19
@nivpgir - Unfortunately since nom is built basically entirely out of macros, the error messages are not very good; they mostly tell you about what's wrong with the code that it generated from what you told it. I've seen error messages like that and it almost always is the case that I did something wrong that is unrelated. I can't spot what it is, offhand, in what you posted above. Maybe it's (id, data) which instead should be ((id, data))? I think it likes parens around the answer.
So you need one set for the tuple and one for the "this is the answer" for do_parse. Just a guess, though.
Denis Lisov
May 17 14:23
IMO, the most likely problem is missing the input parameter which the nom macros usually pass on their own starting from named! or other top-level parser macros... which isn't used here, so it needs to be passed manually.
May 17 14:24
Also, I don't know if what you wrote is valid (e.g. no input, no apparent chaining of results). It certainly doesn't look like any nom code I've written, but I didn't spend much time exploring what was possible.
@tanriol - Yes, that sounds quite likely. Funny that it doesn't crop up until do_parse, though.
Oh, wait, no, that's not strange at all.
do_parse is the first thing that takes I -> IResult<I, _> as arguments.
May 17 16:03
ok... thanks guys, that's important info, I haven't thought out completely on how things are going to work eventually, mostly cause I still don't completely understand whats the workflow with nom.
I just wanted to make sure that I built the parser correctly before trying to use it, and getting it to compile sounded like a good way to verify it.
I guess I'll invest some more thinking, and build an actual main that should work, then see if it compiles.
May 17 16:11
It might be easier to take a working example and change it piece by piece into what you want. I haven't seen any examples that look like your code (storing stuff with let instead of declaring functions).
The docs are almost entirely of the style named!(my_thing, do_parse!(foo: Foo >> bar: Bar >> MyResult{ a: foo, b: bar })).
Denis Lisov
May 17 16:12
@nivpgir If you want less macros and more Rust, it may be a good idea to look at the nom 5 beta... IIRC, they're changing to less macro-oriented and more function-based approach.
May 17 16:17
(I'm really looking forward to a stable nom 5.)
Denis Lisov
May 17 16:18
Same for me, the thing in nom 4 I like the least is that it's not Rust, but a separate language.