"alt" is limited on how many alternatives exist

[csarn]

Hi! I'm trying to write (well, to auto-generate) a disassembler using nom.
So far I have a python script that generates the nom-based parsers for all different instructions.
The problem is that alt can't take many hundreds of alternatives.

Prerequisites

Here are a few things you should provide to help me understand the issue:

• Rust version : rustc 1.45.0 (5c1f21c3b 2020-07-13)
• nom version : 5.1.2
• nom compilation features used: default

Test case

The following minimal example does not compile, and I need something like that to compile.
In my case, of course, the parsers inside the alt are self-written/generated functions that are not easily
combined as in this example.

#[macro_use]
extern crate nom;
use nom::branch::alt;
use nom::IResult;
use nom::character::complete::char;

fn parse_many(i: &str) -> IResult<&str, &str> {
    alt((
        char('a'),
        char('b'),
        char('c'),
        char('d'),
        char('e'),
        char('f'),
        char('g'),
        char('h'),
        char('i'),
        char('j'),
        char('k'),
        char('l'),
        char('m'),
        char('n'),
        char('o'),
        char('p'),
        char('q'),
        char('r'),
        char('s'),
        char('t'),
        char('u'),
        char('v'),
        char('w'),
        char('x'),
        char('y'),
        char('z'),
    ))(i)
}
fn main() {
 assert!("that it compiles".len() > 0);
}

I will try to group my alt expressions, to have nested alts, but it would be nice to allow this, or at least document how to work around that limit.

[ottosson]

You can read a bit about it here #1144

[csarn]

Thanks for the additional information! I did not find that issue while searching, because I limited myself to open issues.
I worked around my issue with nested alts.

I still think this necessity of nesting should appear in the documentation, so maybe this issue can stay open for the documentation fix, or should I create another issue?

[ottosson]

It's always a good idea to check closed issues for solutions 😊

For clarity's sake I would say close this one and open another.

[csarn]

Closed in favor for #1192