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

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 5d09598d48 ("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 <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
This commit is contained in:
Masahiro Yamada 2018-03-13 18:12:06 +09:00
parent 49ac3c0c3a
commit b76960c0f6
4 changed files with 64 additions and 0 deletions

View File

@ -0,0 +1,37 @@
config A
bool "A"
help
This is a new symbol.
choice
prompt "Choice ?"
depends on A
help
"depends on A" has been newly added.
config CHOICE_B
bool "Choice B"
config CHOICE_C
bool "Choice C"
help
This is a new symbol, so should be asked.
endchoice
choice
prompt "Choice2 ?"
config CHOICE_D
bool "Choice D"
config CHOICE_E
bool "Choice E"
config CHOICE_F
bool "Choice F"
depends on A
help
This is a new symbol, so should be asked.
endchoice

View File

@ -0,0 +1,14 @@
"""
Ask new choice values when they become visible.
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.
Related Linux commit: 5d09598d488f081e3be23f885ed65cbbe2d073b5
"""
def test(conf):
assert conf.oldconfig('config', 'y') == 0
assert conf.stdout_contains('expected_stdout')

View File

@ -0,0 +1,3 @@
CONFIG_CHOICE_B=y
# CONFIG_CHOICE_D is not set
CONFIG_CHOICE_E=y

View File

@ -0,0 +1,10 @@
A (A) [N/y/?] (NEW) y
Choice ?
> 1. Choice B (CHOICE_B)
2. Choice C (CHOICE_C) (NEW)
choice[1-2?]:
Choice2 ?
1. Choice D (CHOICE_D)
> 2. Choice E (CHOICE_E)
3. Choice F (CHOICE_F) (NEW)
choice[1-3?]: