There is no grammatical ambiguity by using T_WORD for variables.
The parser can distinguish variables from symbols from the context.

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

Currently, the lexer returns T_ASSIGN for all of =, :=, and +=
associating yylval with the flavor.

I want to make the generated lexer as simple as possible. So, the
lexer should convert keywords to tokens without thinking about the
meaning.

   =  ->  T_EQUAL
  :=  ->  T_COLON_EQUAL
  +=  ->  T_PLUS_EQUAL

Unfortunately, Kconfig uses = instead of == for the equal operator.
So, the same token T_EQUAL is used for assignment and comparison.
The parser can still distinguish them from the context.

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

For the keywords "modules", "defconfig_list", and "allnoconfig_y",
the lexer should pass specific tokens instead of generic T_WORD.

This simplifies both the lexer and the parser.

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

This commit removes kconf_id::stype to prepare for the entire
removal of kconf_id.c

To simplify the lexer, I want keywords straight-mapped to tokens.

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

These are already defined as %left.

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

Now the comment_stmt is the only user of depends_list. Rename it to
comment_option_list

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

Currently, "visible" and "depends on", if defined in a menu entry,
must appear in that order.

The real example is in drivers/media/tuners/Kconfig:

  menu "Customize TV tuners"
          visible if <expr1>
          depends on <expr2>

... is fine, but you cannot change the property order like this:

  menu "Customize TV tuners"
          depends on <expr2>
          visible if <expr1>

Kconfig does not require a specific order of properties. In this case,
menu_add_visibility(() and menu_add_dep() are orthogonal.

Loosen this unreasonable restriction.

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

The code block surrounded by "menu" ... "endmenu" is stmt_list.

Remove the redundant menu_block symbol entirely.

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

The code block surrounded by "if" ... "endif" is stmt_list.

Remove the redundant if_block symbol entirely.

Remove "stmt_list: stmt_list end" rule as well since it would
obviously cause conflicts.

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

This commit decreases 6 shift/reduce conflicts, and finally achieves
conflict-free parser.

Since Kconfig has no terminator for a config block, detecting the end
of config_stmt is not easy.

For example, there are two ways for handling the error in the following
code:

  1 config FOO
  2         =

 [A] Print "unknown option" error, assuming the line 2 is a part of
     config_option_list

 [B] Print "invalid statement", assuming the line 1 is reduced into
     a config_stmt by itself

Bison actually chooses [A] because it performs the shift rather than
the reduction where both are possible.

However, there is no reason to choose one over the other.

Let's remove the option_error, and let it fall back to [B].

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

This commit decreases 15 shift/reduce conflicts.

The location of this error recovery is ambiguous.

For example, there are two ways to interpret the following code:

  1 config FOO
  2         bool "foo"

 [A] Both lines are reduced together into a config_stmt.

 [B] The only line 1 is reduced into a config_stmt, and the line 2
     matches to "option_name error T_EOL"

Of course, we expect [A], but [B] could be grammatically possible.

Kconfig has no terminator for a config block. So, we cannot detect its
end until we see a non-property keyword. People often insert a blank
line between two config blocks, but it is just a coding convention.
Blank lines are actually allowed anywhere in Kconfig files.

The real error is when a property keyword appears right after "endif",
"endchoice", "endmenu",  "source", "comment", or variable assignment.

Instead of fixing the grammatical ambiguity, I chose to simply remove
this error recovery.

The difference is

  unexpected option "bool"

... is turned into a more generic message:

  invalid statement

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

It would be nice to warn if a new line is missing at end of file.

We could do this by checkpatch.pl for arbitrary files, but new line
is rather essential as a statement terminator in Kconfig.

The warning message looks like this:

  kernel/Kconfig.preempt:60:warning: no new line at end of file

Currently, kernel/Kconfig.preempt is the only file with no new line
at end of file. Fix it.

I know there are some false negative cases. For example, no warning
is displayed when the last line contains some whitespaces/comments,
but no new line. Yet, this commit works well for most cases.

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

A new file should always start in the INITIAL state.

When the lexer bumps into EOF, the lexer must get back to the INITIAL
state anyway. Remove the redundant <<EOF>> pattern in the PARAM state.

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

This commit decreases 8 shift/reduce conflicts.

A certain amount of grammatical ambiguity comes from how to reduce
excessive T_EOL tokens.

Let's take a look at the example code below:

  1  config A
  2          bool "a"
  3
  4          depends on B
  5
  6  config B
  7          def_bool y

The line 3 is melt into "config_option_list", but the line 5 can be
either a part of "config_option_list" or "common_stmt" by itself.

Currently, the lexer converts '\n' to T_EOL verbatim. In Kconfig,
a new line works as a statement terminator, but new lines in empty
lines are not critical since empty lines (or lines that contain only
whitespaces/comments) are just no-op.

If the lexer simply discards no-op lines, the parser will not be
bothered by excessive T_EOL tokens.

Of course, this means we are shifting the complexity from the parser
to the lexer, but it is much easier than tackling on shift/reduce
conflicts.

I introduced the second stage lexer to tweak the behavior.

Discard T_EOL if the previous token is T_EOL or T_HELPTEXT.
Two T_EOL tokens in a row is meaningless. T_HELPTEXT is a special
token that is reduced without T_EOL.

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

Here, similar matching patters are duplicated in order to look ahead
the '\n' character. If the next character is '\n', the lexer returns
T_WORD_QUOTE because it must be prepared to return T_EOL at the next
match.

Use unput('\n') trick to reduce the code duplication.

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

Whitespaces are consumed in the COMMAND state anyway.

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

All line-oriented statements should be reduced when seeing a T_EOL
token. I guess missing T_EOL for the "visible" statement is just a
mistake. This commit decreases one shift/reduce conflict.

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

An unterminated string literal followed by new line is passed to the
parser (with "multi-line strings not supported" warning shown), then
handled properly there.

On the other hand, an unterminated string literal at end of file is
never passed to the parser, then results in memory leak.

[Test Code]

  ----------(Kconfig begin)----------
  source "Kconfig.inc"

  config A
          bool "a"
  -----------(Kconfig end)-----------

  --------(Kconfig.inc begin)--------
  config B
          bool "b\No new line at end of file
  ---------(Kconfig.inc end)---------

[Summary from Valgrind]

  Before the fix:

    LEAK SUMMARY:
       definitely lost: 16 bytes in 1 blocks
       ...

  After the fix:

    LEAK SUMMARY:
       definitely lost: 0 bytes in 0 blocks
       ...

Eliminate the memory leak path by handling this case. Of course, such
a Kconfig file is wrong already, so I will add an error message later.

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

Currently, warn_ignore_character() displays invalid file name and
line number.

The lexer should use current_file->name and yylineno, while the parser
should use zconf_curname() and zconf_lineno().

This difference comes from that the lexer is always going ahead
of the parser. The parser needs to look ahead one token to make a
shift/reduce decision, so the lexer is requested to scan more text
from the input file.

This commit fixes the warning message from warn_ignored_character().

[Test Code]

  ----(Kconfig begin)----
  /
  -----(Kconfig end)-----

[Output]

  Before the fix:

  <none>:0:warning: ignoring unsupported character '/'

  After the fix:

  Kconfig:1:warning: ignoring unsupported character '/'

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

The only possibility of k_invalid being returned was when
expr_parse_sting() parsed S_OTHER type symbol. This actually never
happened, and this is even clearer since S_OTHER has gone.

Clean up unreachable code.

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

The S_OTHER type could be set only when conf_read_simple() is reading
include/config/auto.conf file.

For example, CONFIG_FOO=y exists in include/config/auto.conf but it is
missing from the currently parsed Kconfig files, sym_lookup() allocates
a new symbol, and sets its type to S_OTHER.

Strangely, it will be set to S_STRING by conf_set_sym_val() a few lines
below while it is obviously bool or tristate type. On the other hand,
when CONFIG_BAR="bar" is being dropped from include/config/auto.conf,
its type remains S_OTHER. Because for_all_symbols() omits S_OTHER
symbols, conf_touch_deps() misses to touch include/config/bar.h

This behavior has been a pretty mystery for me, and digging the git
histroy did not help. At least, touching depfiles is broken for string
type symbols.

I removed S_OTHER entirely, and reimplemented it more simply.

If CONFIG_FOO was visible in the previous syncconfig, but is missing
now, what we want to do is quite simple; just call conf_touch_dep()
to touch include/config/foo.h instead of allocating a new symbol data.

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

conf_touch_deps() iterates over symbols, touching corresponding
include/config/*.h files as needed.

Split the part that touches a single file into a new helper so it can
be reused.

The new helper, conf_touch_dep(), takes a symbol name as a parameter,
and touches the corresponding include/config/*.h file.

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

According to commit 2e3646e5 ("kconfig: integrate split config
into silentoldconfig"), this function was named after split-include
tool, which used to exist in old versions of Linux.

Setting aside the historical reason, rename it into a more intuitive
name. This function touches timestamp files under include/config/
in order to interact with the fixdep tool.

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

The two 'goto setsym' statements are reachable only when sym == NULL.

The code below the 'setsym:' label does nothing when sym == NULL
since there is just one if-block guarded by 'if (sym && ...)'.

Hence, 'goto setsym' can be replaced with 'continue'.

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

In today's merge_config.sh the order of the config fragment files dictates
the output of a config option. With this approach we will get different
.config files depending on the order of the config fragment files.

So doing something like:
$ ./merge/kconfig/merge_config.sh selftest.config drm.config

Where selftest.config defines DRM=y and drm.config defines DRM=m, the
result will be "DRM=m".

Rework to add a switch to get builtin '=y' precedence over modules '=m',
this will result in "DRM=y". If we do something like this:

$ ./merge/kconfig/merge_config.sh -y selftest.config drm.config

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Commit 37c8a5fa ("kbuild: consolidate Devicetree dtb build rules")
moved the location of 'dtbs_install' target which caused dtbs to not be
installed when building debian package with 'bindeb-pkg' target. Update
the builddeb script to use the same logic that determines if there's a
'dtbs_install' target which is presence of the arch dts directory. Also,
use CONFIG_OF_EARLY_FLATTREE instead of CONFIG_OF as that's a better
indication of whether we are building dtbs.

This commit will also have the side effect of installing dtbs on any
arch that has dts files. Previously, it was dependent on whether the
arch defined 'dtbs_install'.

Fixes: 37c8a5fa ("kbuild: consolidate Devicetree dtb build rules")
Reported-by: Nuno Gonçalves <nunojpg@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

This reverts commit 6147b1cf.

The reverted patch results in attempted write access to the source
repository, even if that repository is mounted read-only.

Output from "strace git status -uno --porcelain":

getcwd("/tmp/linux-test", 129)          = 16
open("/tmp/linux-test/.git/index.lock", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0666) =
	-1 EROFS (Read-only file system)

While git appears to be able to handle this situation, a monitored
build environment (such as the one used for Chrome OS kernel builds)
may detect it and bail out with an access violation error. On top of
that, the attempted write access suggests that git _will_ write to the
file even if a build output directory is specified. Users may have the
reasonable expectation that the source repository remains untouched in
that situation.

Fixes: 6147b1cf ("scripts/setlocalversion: git: Make -dirty check more robust"
Cc: Genki Sky <sky@genki.is>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Since commit b41d920a ("kbuild: deb-pkg: split generating packaging
and build"), the build version of the kernel contained in a deb package
is too low by 1.

Prior to the bad commit, the kernel was built first, then the number
in .version file was read out, and written into the debian control file.

Now, the debian control file is created before the kernel is actually
compiled, which is causing the version number mismatch.

Let the mkdebian script pass KBUILD_BUILD_VERSION=${revision} to require
the build system to use the specified version number.

Fixes: b41d920a ("kbuild: deb-pkg: split generating packaging and build")
Reported-by: Doug Smythies <dsmythies@telus.net>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Doug Smythies <dsmythies@telus.net>

The current SED_CONFIG_EXP could match to comment lines in config
fragment files, especially when CONFIG_PREFIX_ is empty. For example,
Buildroot uses empty prefixing; starting symbols with BR2_ is just
convention.

Make the sed expression more robust against false positives from
comment lines. The new sed expression matches to only valid patterns.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Petr Vorel <petr.vorel@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

Ard Biesheuvel reports bindeb-pkg with O= option is broken in the
following way:

  ...
    LD [M]  sound/soc/rockchip/snd-soc-rk3399-gru-sound.ko
    LD [M]  sound/soc/rockchip/snd-soc-rockchip-pcm.ko
    LD [M]  sound/soc/rockchip/snd-soc-rockchip-rt5645.ko
    LD [M]  sound/soc/rockchip/snd-soc-rockchip-spdif.ko
    LD [M]  sound/soc/sh/rcar/snd-soc-rcar.ko
   fakeroot -u debian/rules binary
  make KERNELRELEASE=4.19.0-12677-g19beffaf7a99-dirty ARCH=arm64 KBUILD_SRC= intdeb-pkg
  /bin/bash /home/ard/linux/scripts/package/builddeb
  Makefile:600: include/config/auto.conf: No such file or directory
  ***
  *** Configuration file ".config" not found!
  ***
  *** Please run some configurator (e.g. "make oldconfig" or
  *** "make menuconfig" or "make xconfig").
  ***
  make[12]: *** [syncconfig] Error 1
  make[11]: *** [syncconfig] Error 2
  make[10]: *** [include/config/auto.conf] Error 2
  make[9]: *** [__sub-make] Error 2
  ...

Prior to commit 80463f1b ("kbuild: add --include-dir flag only
for out-of-tree build"), both srctree and objtree were added to
--include-dir redundantly, and the wrong code '$MAKE image_name'
was working by relying on that. Now, the potential issue that had
previously been hidden just showed up.

'$MAKE image_name' recurses to the generated $(objtree)/Makefile and
ends up with running in srctree, which is incorrect. It should be
invoked with '-f $srctree/Makefile' (or KBUILD_SRC=) to be executed
in objtree.

Fixes: 80463f1b ("kbuild: add --include-dir flag only for out-of-tree build")
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

Zhenzhong Duan reported that running 'make O=/build/kernel binrpm-pkg'
failed with the following errors:

  Running 'make O=/build/kernel binrpm-pkg' failed with below two errors.

  Makefile:600: include/config/auto.conf: No such file or directory

  + cp make -C /mnt/root/kernel O=/build/kernel image_name make -f
  /mnt/root/kernel/Makefile ...
  cp: invalid option -- 'C'
  Try 'cp --help' for more information.

Prior to commit 80463f1b ("kbuild: add --include-dir flag only
for out-of-tree build"), both srctree and objtree were added to
--include-dir redundantly, and the wrong code 'make image_name'
was working by relying on that. Now, the potential issue that had
previously been hidden just showed up.

'make image_name' recurses to the generated $(objtree)/Makefile and
ends up with running in srctree, which is incorrect. It should be
invoked with '-f $srctree/Makefile' (or KBUILD_SRC=) to be executed
in objtree.

Fixes: 80463f1b ("kbuild: add --include-dir flag only for out-of-tree build")
Reported-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

There is one more user of $(cc-name) in the top Makefile. It is supposed
to detect Clang before invoking Kconfig, so it should still be there
in the $(shell ...) form. All the other users of $(cc-name) have been
replaced with $(CONFIG_CC_IS_CLANG). Hence, scripts/Kbuild.include does
not need to define cc-name any more.

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

Evaluating cc-name invokes the compiler every time even when you are
not compiling anything, like 'make help'. This is not efficient.

The compiler type has been already detected in the Kconfig stage.
Use CONFIG_CC_IS_CLANG, instead.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Acked-by: Paul Burton <paul.burton@mips.com> (MIPS)
Acked-by: Joel Stanley <joel@jms.id.au>

with CONFIG_ environment variable.

merge_config.sh uses CONFIG_ which is used in kernel and other projects.
There are some projects which use kconfig with different prefixes (e.g.
buildroot: BR2_ prefix). CONFIG_ variable is already used for this
purpose in kconfig binary (scripts/kconfig/lkc.h), let's use the same
rule for in merge_config.sh.

Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

The last user of cc-fullversion was removed by commit f2910f0e
("powerpc: remove old GCC version checks").

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

As commit 911a91c3 ("kconfig: rename silentoldconfig to
syncconfig") announced, it is time for the removal.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

As commit 312ee687 ("kconfig: announce removal of oldnoconfig if
used") announced, it is time for the removal.

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

This warning was there to avoid the use of 0bxxx values as they are not
supported by gcc prior to v4.3

Since cafa0010 ("Raise the minimum required gcc version to 4.6"),
it's not an issue anymore and using such values can increase readability
of code.

Joe said:

: Seems sensible as the other compilers also support binary literals from
: relatively old versions.
: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf
: https://software.intel.com/en-us/articles/c14-features-supported-by-intel-c-compiler

Link: http://lkml.kernel.org/r/392eeae782302ee8812a3c932a602035deed1609.1535351453.git.christophe.leroy@c-s.fr


Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Create DEF_FIELD_ADDR_VAR as a more generic version of the DEF_FIELD_ADD
macro, allowing usage of a variable name other than the struct element name.
Also, sets DEF_FIELD_ADDR as a specific usage of DEF_FILD_ADDR_VAR in which
the var name is the same as the struct element name.
Then, makes use of DEF_FIELD_ADDR_VAR to create a variable of another name,
in order to avoid variable shadowing.

Signed-off-by: Leonardo Bras <leobras.c@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Remove an unnecessary shadowed local variable (start).
It was used only once, with the same value it was started before
the if block.

Signed-off-by: Leonardo Bras <leobras.c@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>