linux.git/scripts/kconfig/tests, branch v4.18.8

kconfig: test: add Kconfig macro language tests

2018-05-28T18:31:19+00:00

Here are the test cases I used for developing the text expansion
feature.

Signed-off-by: Masahiro Yamada

kconfig: make default prompt of mainmenu less specific

2018-05-28T18:31:19+00:00

If "mainmenu" is not specified, "Linux Kernel Configuration" is used
as a default prompt.

Given that Kconfig is used in other projects than Linux, let's use
a more generic prompt, "Main menu".

Suggested-by: Sam Ravnborg 
Signed-off-by: Masahiro Yamada

kconfig: remove duplicated file name and lineno of recursive inclusion

2018-03-25T17:04:06+00:00

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

kconfig: tests: test if recursive inclusion is detected

2018-03-25T17:04:05+00:00

If recursive inclusion is detected, it should fail with error
messages.  Test this.

This also tests the line numbers in the error message, fixed by
commit 5ae6fcc4bb82 ("kconfig: fix line number in recursive inclusion
error message").

Signed-off-by: Masahiro Yamada 
Reviewed-by: Ulf Magnusson

kconfig: tests: test if recursive dependencies are detected

2018-03-25T17:04:04+00:00

Recursive dependency should be detected and warned.  Test this.

This indirectly tests the line number increments.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Ulf Magnusson

kconfig: tests: test randconfig for choice in choice

2018-03-25T17:04:04+00:00

Commit 3b9a19e08960 ("kconfig: loop as long as we changed some symbols
in randconfig") fixed randconfig where a choice contains a sub-choice.
Prior to that commit, the sub-choice values were not set.

I am not sure whether this is an intended feature or just something
people discovered works, but it is used in the real world;
drivers/usb/gadget/legacy/Kconfig is source'd in a choice context,
then creates a sub-choice in it.

For the test case in this commit, there are 3 possible results.

Case 1:
  CONFIG_A=y
  # CONFIG_B is not set

Case 2:
  # CONFIG_A is not set
  CONFIG_B=y
  CONFIG_C=y
  # CONFIG_D is not set

Case 3:
  # CONFIG_A is not set
  CONFIG_B=y
  # CONFIG_C is not set
  CONFIG_D=y
  CONFIG_E=y

So, this test iterates several times, and checks if the result is
either of the three.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Ulf Magnusson

kconfig: tests: test defconfig when two choices interact

2018-03-25T17:04:04+00:00

Commit fbe98bb9ed3d ("kconfig: Fix defconfig when one choice menu
selects options that another choice menu depends on") fixed defconfig
when two choices interact (i.e. calculating the visibility of a choice
requires to calculate another choice).

The test code in that commit log was based on the real world example,
and complicated.  So, I shrunk it down to the following:

defconfig.choice:
---8<---
CONFIG_CHOICE_VAL0=y
---8<---

---8<---
config MODULES
        def_bool y
        option modules

choice
        prompt "Choice"

config CHOICE_VAL0
        tristate "Choice 0"

config CHOICE_VAL1
        tristate "Choice 1"

endchoice

choice
        prompt "Another choice"
        depends on CHOICE_VAL0

config DUMMY
        bool "dummy"

endchoice
---8<---

Prior to commit fbe98bb9ed3d,

  $ scripts/kconfig/conf --defconfig=defconfig.choice Kconfig.choice

resulted in:

  CONFIG_MODULES=y
  CONFIG_CHOICE_VAL0=m
  # CONFIG_CHOICE_VAL1 is not set
  CONFIG_DUMMY=y

where the expected result would be:

  CONFIG_MODULES=y
  CONFIG_CHOICE_VAL0=y
  # CONFIG_CHOICE_VAL1 is not set
  CONFIG_DUMMY=y

Roughly, this weird behavior happened like this:

Symbols are calculated a couple of times.  First, all symbols are
calculated in conf_read().  The first 'choice' is evaluated to 'y'
due to the SYMBOL_DEF_USER flag, but sym_calc_choice() clears it
unless all of its choice values are explicitly set by the user.

conf_set_all_new_symbols() clears all SYMBOL_VALID flags.  Then, only
choices are calculated.  Here, the SYMBOL_DEF_USER for the first choice
has been forgotten, so it is evaluated to 'm'.  set_all_choice_values()
sets SYMBOL_DEF_USER again to choice symbols.

When calculating the second choice, due to 'depends on CHOICE_VAL0',
it triggers the calculation of CHOICE_VAL0.  As a result, SYMBOL_VALID
is set for CHOICE_VAL0.

Symbols except choices get the final chance of re-calculation in
conf_write().  In a normal case, CHOICE_VAL0 would be re-calculated,
then the first choice would be indirectly re-calculated with the
SYMBOL_DEF_USER which has been recalled by set_all_choice_values(),
which would be evaluated to 'y'.  But, in this case, CHOICE_VAL0 has
already been marked as SYMBOL_VALID, so this re-calculation does not
happen.  Then, =m from the conf_set_all_new_symbols() phase is written
out to the .config file.

Add a unit test for this naive case.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Ulf Magnusson

kconfig: tests: check visibility of tristate choice values in y choice

2018-03-25T17:04:03+00:00

If tristate choice values depend on symbols set to 'm', they should be
hidden when the choice containing them is changed from 'm' to 'y'
(i.e. exclusive choice).

This issue was fixed by commit fa64e5f6a35e ("kconfig/symbol.c: handle
choice_values that depend on 'm' symbols").

Add a test case to avoid regression.

For the input in this unit test, there is a room for argument if
"# CONFIG_CHOICE1 is not set" should be written to the .config file.

After commit fa64e5f6a35e, this line was written to the .config file.

With commit cb67ab2cd2b8 ("kconfig: do not write choice values when
their dependency becomes n"), it is not written now.

In this test, "# CONFIG_CHOICE1 is not set" is don't care.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Ulf Magnusson

kconfig: tests: check unneeded "is not set" with unmet dependency

2018-03-25T17:04:03+00:00

Commit cb67ab2cd2b8 ("kconfig: do not write choice values when their
dependency becomes n") fixed a problem where "# CONFIG_... is not set"
for choice values are wrongly written into the .config file when they
are once visible, then become invisible later.

Add a test for this naive case.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Ulf Magnusson

kconfig: tests: test if new symbols in choice are asked

2018-03-25T17:04:03+00:00

If new choice values are added with new dependency, and they become
visible during user configuration, oldconfig should recognize them
as (NEW), and ask the user for choice.

This issue was fixed by commit 5d09598d488f ("kconfig: fix new choices
being skipped upon config update").

This is a subtle corner case.  Add a test case to avoid breakage.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Ulf Magnusson