kconfig: report recursive dependency involving 'imply'
authorMasahiro Yamada <yamada.masahiro@socionext.com>
Wed, 15 Aug 2018 05:59:44 +0000 (14:59 +0900)
committerChristian Lamparter <chunkeey@gmail.com>
Sun, 10 Feb 2019 21:27:12 +0000 (22:27 +0100)
commit4b50ce9a0f1d39c85507e10e24288ab20d111aa4
tree8d8c47400d97f5d1a2b598616f4886b0c8e84c1b
parentec9933f517d25d4bb9026766916da160f10f119d
kconfig: report recursive dependency involving 'imply'

Currently, Kconfig does not complain about the recursive dependency
where 'imply' keywords are involved.

[Test Code]

  config A
          bool "a"

  config B
          bool "b"
          imply A
          depends on A

In the code above, Kconfig cannot calculate the symbol values correctly
due to the circular dependency.  For example, allyesconfig followed by
syncconfig results in an odd behavior because CONFIG_B becomes visible
in syncconfig.

  $ make allyesconfig
  scripts/kconfig/conf  --allyesconfig Kconfig
  #
  # configuration written to .config
  #
  $ cat .config
  #
  # Automatically generated file; DO NOT EDIT.
  # Main menu
  #
  CONFIG_A=y
  $ make syncconfig
  scripts/kconfig/conf  --syncconfig Kconfig
  *
  * Restart config...
  *
  *
  * Main menu
  *
  a (A) [Y/n/?] y
    b (B) [N/y/?] (NEW)

To detect this correctly, sym_check_expr_deps() should recurse to
not only sym->rev_dep.expr but also sym->implied.expr .

At this moment, sym_check_print_recursive() cannot distinguish
'select' and 'imply' since it does not know the precise context
where the recursive dependency has been hit.  This will be solved
by the next commit.

In fact, even the document and the unit-test are confused.  Using
'imply' does not solve recursive dependency since 'imply' addresses
the unmet direct dependency, which 'select' could cause.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Dirk Gouders <dirk@gouders.net>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
config/symbol.c