rules: always initialize idx variable

gcc didn't catch this one.

Signed-off-by: Ran Benita <ran234@gmail.com>
Don't use %z printf format

Some libc's don't support it.

Signed-off-by: Ran Benita <ran234@gmail.com>
test/interactive: allow -k to get any absolute path

Instead of looking for a keymap in test/data.

Signed-off-by: Ran Benita <ran234@gmail.com>
parser: remove XkbConfig rule

This rule allows you to write file maps as:
    xkb_keycodes
    <BLA> = 5;
    [...]
instead of the usual format which is:
    xkb_keycodes {
        <BLA> = 5;
        [...]
    };

This is not documented, It is also not used in xkeyboard-config, and I
have never run into it otherwise. It also only allows one map per file.

It *might* be used in some obscure place, but probably nothing we should
care about; the simplified grammar is more useful for us now.

Signed-off-by: Ran Benita <ran234@gmail.com>
parser: remove XkbCompMapList rule

This rule allows you to put several xkb_keymaps in one file.
This doesn't make any sense: only the default/first can ever be used,
yet the others are fully parsed as well.
Different keymaps should just be put in different files.

Signed-off-by: Ran Benita <ran234@gmail.com>
scanner: remove uselss 'last symbol' error message

It never shows something useful. Besides, you already get the line
number, which is enough.

Signed-off-by: Ran Benita <ran234@gmail.com>
scanner: share code in XkbParse{File,String}

Some refactoring to prepare for changes in the parse() function.

Signed-off-by: Ran Benita <ran234@gmail.com>
scanner: don't strdup the file name

We don't modify it and there's no way to modify the original in the
scanner_extra life time.

Signed-off-by: Ran Benita <ran234@gmail.com>
Don't scan and parse useless maps

One physical xkb file may (and usually does) contain multiple maps. For
example, the us symbols file contains a map for every variant.
Currently, when we need a map from a file (specific or default), we
parse the entire file into a list of XkbFile's, find the map we want and
discard the others. This happens for every include statement. This is a lot
of unnecessary work; this commit is a first step at making it better.

What we do now is make yyparse return one map at a time; if we find what
we want, we can stop looking and avoid processing the rest of the file.

This moves some logic from include.c to parser.y (i.e. finding the
correct map, named or default). It also necessarily removes the
CheckDefaultMap check, which warned about a file which contains multiple
default maps. We can live without it.

Some stats with test/rulecomp (under valgrind and the benchmark):

Before:
==2280==   total heap usage: 288,665 allocs, 288,665 frees, 13,121,349 bytes allocated
compiled 1000 keymaps in 10.849487353s

After:
==1070==   total heap usage: 100,197 allocs, 100,197 frees, 9,329,900 bytes allocated
compiled 1000 keymaps in 5.258960549s

Pretty good.

Note: we still do some unnecessary work, by parsing and discarding the
maps before the one we want. However dealing with this is more
complicated (maybe using bison's push-parser and sniffing the token
stream). Probably not worth it.

Signed-off-by: Ran Benita <ran234@gmail.com>