This flag is unneeded because a choice member can be detected by
other means.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

sym_get_choice_value(menu->sym) is equivalent to sym_calc_choice(menu).

Convert all call sites of sym_get_choice_value() and then remove it.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

I previously submitted a fix for a bug in the choice feature [1], where
I mentioned, "Another (much cleaner) approach would be to remove the
tristate choice support entirely".

There are more issues in the tristate choice feature. For example, you
can observe a couple of bugs in the following test code.

[Test Code]

    config MODULES
            def_bool y
            modules

    choice
            prompt "tristate choice"
            default A

    config A
            tristate "A"

    config B
            tristate "B"

    endchoice

Bug 1: the 'default' property is not correctly processed

'make alldefconfig' produces:

    CONFIG_MODULES=y
    # CONFIG_A is not set
    # CONFIG_B is not set

However, the correct output should be:

    CONFIG_MODULES=y
    CONFIG_A=y
    # CONFIG_B is not set

The unit test file, scripts/kconfig/tests/choice/alldef_expected_config,
is wrong as well.

Bug 2: choice members never get 'y' with randconfig

For the test code above, the following combinations are possible:

               A    B
        (1)    y    n
        (2)    n    y
        (3)    m    m
        (4)    m    n
        (5)    n    m
        (6)    n    n

'make randconfig' never produces (1) or (2).

These bugs are fixable, but a more critical problem is the lack of a
sensible syntax to specify the default for the tristate choice.
The default for the choice must be one of the choice members, which
cannot specify any of the patterns (3) through (6) above.

In addition, I have never seen it being used in a useful way.

The following commits removed unnecessary use of tristate choices:

 - df8df5e4bc37 ("usb: get rid of 'choice' for legacy gadget drivers")
 - bfb57ef0544a ("rapidio: remove choice for enumeration")

This commit removes the tristate choice support entirely, which allows
me to delete a lot of code, making further refactoring easier.

Note:
This includes the revert of commit fa64e5f6a35e ("kconfig/symbol.c:
handle choice_values that depend on 'm' symbols"). It was suspicious
because it did not address the root cause but introduced inconsistency
in visibility between choice members and other symbols.

[1]: https://lore.kernel.org/linux-kbuild/20240427104231.2728905-1-masahiroy@kernel.org/T/#m0a1bb6992581462ceca861b409bb33cb8fd7dbae

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>

Commit ee06a3ef7e3c ("kconfig: Update config changed flag before calling
callback") pointed out that conf_updated flag must be updated _before_
calling the callback, which needs to know the new value.

Given that, it makes sense to directly pass the new value to the
callback.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Define conf_changed() before its call site to remove the forward
declaration.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

These are defined before their call sites.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Currently, the initial state of the "Save" button is always active.

If none of the CONFIG options are changed while loading the .config
file, the "Save" button should be greyed out.

This can be fixed by calling conf_read() after widget initialization.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Currently, bool choices have a checkbox, but tristate choices do not.
It is opposite.

Bool choices should not have a checkbox, as they are fixed to 'y' since
commit 6a1215888e23 ("kconfig: remove 'optional' property support").
Tristate choices, however, should have a checkbox to allow users to
toggle the value.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

SYMBOL_CHANGED and MENU_CHANGED are used to update GUI frontends
when the symbol value is changed. These are used inconsistently:
SYMBOL_CHANGED in gconf.c and MENU_CHANGE in qconf.cc.

MENU_CHANGED works more properly when a symbol has multiple prompts
(although such code is not ideal).

[test code]

    config FOO
            bool "foo prompt 1"

    config FOO
            bool "foo prompt 2"

In gconfig, if one of the two checkboxes is clicked, only the first
one is toggled. In xconfig, the two checkboxes work in sync.

Replace SYMBOL_CHANGED in gconf.c with MENU_CHANGED to align with
the xconfig behavior.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

This is not so useful. If necessary, you can insert printf() or
whatever during debugging.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>