Tracking the line number by hand is error-prone since you need to
increment it in every \n matching pattern.

If '%option yylineno' is set, flex defines 'yylineno' to contain the
current line number and automatically updates it each time it reads a
\n character.  This is much more convenient although the lexer does
not initializes yylineno, so you need to set it to 1 each time you
start reading a new file, and restore it you go back to the previous
file.

I tested this with DEBUG_PARSE, and confirmed the same dump message
was produced.

I removed the perf-report option.  Otherwise, I see the following
message:
  %option yylineno entails a performance penalty ONLY on rules that
  can match newline characters

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Currently, the recursive inclusion is not detected when the offending
file is about to be included; it is detected the offending file is
about to include the *next* file.  This is because the detection loop
does not involve the file being included.

Do this check against the file that is about to be included so that
the recursive inclusion is detected before unneeded parsing happens.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

As in the unit test, the error message for the recursive inclusion
looks like this:

  Kconfig.inc1:4: recursive inclusion detected. Inclusion path:
    current file : 'Kconfig.inc1'
    included from: 'Kconfig.inc3:1'
    included from: 'Kconfig.inc2:3'
    included from: 'Kconfig.inc1:4'

The 'Kconfig.inc1:4' is duplicated in the first and last lines.
Also, the single quotes do not help readability.

Change the message like follows:

  Recursive inclusion detected.
  Inclusion path:
    current file : Kconfig.inc1
    included from: Kconfig.inc3:1
    included from: Kconfig.inc2:3
    included from: Kconfig.inc1:4

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

When recursive inclusion is detected, the line number of the last
'included from:' is wrong.

[Test Case]

Kconfig:
  -------->8--------
  source "Kconfig2"
  -------->8--------

Kconfig2:
  -------->8--------
  source "Kconfig3"
  -------->8--------

Kconfig3:
  -------->8--------
  source "Kconfig"
  -------->8--------

[Result]

  $ make allyesconfig
  scripts/kconfig/conf  --allyesconfig Kconfig
  Kconfig:1: recursive inclusion detected. Inclusion path:
    current file : 'Kconfig'
    included from: 'Kconfig3:1'
    included from: 'Kconfig2:1'
    included from: 'Kconfig:3'
  scripts/kconfig/Makefile:89: recipe for target 'allyesconfig' failed
  make[1]: *** [allyesconfig] Error 1
  Makefile:512: recipe for target 'allyesconfig' failed
  make: *** [allyesconfig] Error 2

where we expect

    current file : 'Kconfig'
    included from: 'Kconfig3:1'
    included from: 'Kconfig2:1'
    included from: 'Kconfig:1'

The 'iter->lineno+1' in the second fpinrtf() should be 'iter->lineno-1'.
I refactored the code to merge the two fprintf() calls.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>

We already have xmalloc(), xcalloc().  Add xrealloc() as well
to save tedious error handling.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

These messages should be directed to stderr.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>

Flex and Bison provide an option to change the prefix of globally-
visible symbols.  This is useful to link multiple lexers and/or
parsers into the same executable.  However, Kconfig (and any other
host programs in kernel) uses a single lexer and parser.  I do not
see a good reason to change the default 'yy' prefix.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>

In Kconfig, definitions of options take the following form:
"<COMMAND> <PARAM> <PARAM> ...". COMMANDs and PARAMs are treated
slightly different by the underlying parser.

While commit 2e0d737fc76f ("kconfig: don't silently ignore unhandled
characters") introduced a warning for unsupported characters around
PARAMs, it does not cover situations where a COMMAND has additional
characters before it.

This change makes Kconfig emit a warning if superfluous characters
are found before COMMANDs. As the 'help' statement sometimes is
written as '---help---', the '-' character would now also be regarded
as unhandled and generate a warning. To avoid that, '-' is added to
the list of allowed characters, and the token '---help---' is included
in the zconf.gperf file.

Reported-by: Valentin Rothberg <valentinrothberg@gmail.com>
Signed-off-by: Andreas Ruprecht <andreas.ruprecht@fau.de>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
Tested-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.com>

Over the years I found it desirable to be able to use all sorts of
relations, not just (in)equality. And apparently I'm not the only one,
as there's at least one example in the tree where the programmer
assumed this would work (see DEBUG_UART_8250_WORD in
arch/arm/Kconfig.debug). Another possible use would e.g. be to fold the
two SMP/NR_CPUS prompts into one: SMP could be promptless, simply
depending on NR_CPUS > 1.

A (desirable) side effect of this change - resulting from numeric
values now necessarily being compared as numbers rather than as
strings - is that comparing hex values now works as expected: Other
than int ones (which aren't allowed to have leading zeroes), zeroes
following the 0x prefix made them compare unequal even if their values
were equal.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>

At the very least we should tell people that what they wrote is not
what the utility understands.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Michal Marek <mmarek@suse.cz>