Fixed a typo in some variables where height was misspelled as heigth.
Signed-off-by: Isak Ellmer <isak01@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The boolean 'choice' is used to list exclusively selected config
options.
You must not add a dependency between choice members, because such a
dependency would create an invisible entry.
In the following test case, it is impossible to choose 'C'.
[Test Case 1]
choice
prompt "Choose one, but how to choose C?"
config A
bool "A"
config B
bool "B"
config C
bool "C"
depends on A
endchoice
Hence, Kconfig shows the following error message:
Kconfig:1:error: recursive dependency detected!
Kconfig:1: choice <choice> contains symbol C
Kconfig:10: symbol C is part of choice A
Kconfig:4: symbol A is part of choice <choice>
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"
However, Kconfig does not report anything for the following similar code:
[Test Case 2]
choice
prompt "Choose one, but how to choose B?"
config A
bool "A"
config B
bool "B"
depends on A
config C
bool "C"
endchoice
This is because menu_finalize() reparents the menu tree when an entry
depends on the preceding one.
With reparenting, the menu tree:
choice
|- A
|- B
\- C
... will be transformed into the following structure:
choice
|- A
| \- B
\- C
Consequently, Kconfig considers only 'A' and 'C' as choice members.
This behavior is awkward. The second test case should be an error too.
This commit stops reparenting inside a choice.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Commit c8fb7d7e48 ("kconfig: fix broken dependency in randconfig-
generated .config") fixed the issue, but I did not add a test case.
This commit adds a test case that emulates the reported situation.
The test would fail without c8fb7d7e48.
To handle the choice "choose X", FOO must be calculated beforehand.
FOO depends on A, which is a member of another choice "choose A or B".
Kconfig _temporarily_ assumes the value of A to proceed. The choice
"choose A or B" will be shuffled later, but the result may or may not
meet "FOO depends on A". Kconfig should invalidate the symbol values
and recompute them.
In the real example for ARCH=arm64, the choice "Instrumentation type"
needs the value of CPU_BIG_ENDIAN. The choice "Endianness" will be
shuffled later.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Since commit 3b9a19e089 ("kconfig: loop as long as we changed some
symbols in randconfig"), conf_set_all_new_symbols() is repeated until
there is no more choice left to be shuffled. The motivation was to
shuffle a choice nested in another choice.
Although commit 09d5873e4d ("kconfig: allow only 'config', 'comment',
and 'if' inside 'choice'") disallowed the nested choice structure,
we must still keep 3b9a19e089 because there are still cases where
conf_set_all_new_symbols() must iterate.
scripts/kconfig/tests/choice_randomize/Kconfig is the test case.
The second choice depends on 'B', which is the member of the first
choice.
With 3b9a19e089 reverted, we would never get the pattern specified by
scripts/kconfig/tests/choice_randomize/expected_config2.
A real example can be found in lib/Kconfig.debug. Without 3b9a19e089,
the randconfig would not shuffle the "Compressed Debug information"
choice, which depends on DEBUG_INFO, which is derived from another
choice "Debug information".
My goal is to refactor Kconfig so that randconfig will work more
simply, without using the loop.
For now, let's add a test case to ensure all dependent choices are
shuffled, as it is a somewhat tricky case for the current Kconfig.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
When the condition 'sym == NULL' is met, the code will reach the
'next_menu' label regardless of the return value from menu_is_visible().
menu_is_visible() calculates some symbol values as a side-effect, for
instance by calling expr_calc_value(menu->visibility), but all the
symbol values will be calculated eventually.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Remove inputbox_order, searchbox, searchbox_title, searchbox_border
because they are initialized, but not used anywhere.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
For MENUCONFIG_COLOR=blackbg, the text in inactive buttons is invisible
because both the foreground and background are black.
Change the foreground color to white and remove the highlighting.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Commit 5a1aa8a1af ("kconfig: add named choice group") did not provide
enough explanation regarding its benefits. A use case was found in
another project [1] sometime later, this feature has never been used in
the kernel.
[1]: https://lore.kernel.org/all/201012150034.01356.yann.morin.1998@anciens.enib.fr/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Currently, get_symbol_str() uses a tricky approach to traverse the
associated menus.
With relevant menus now linked to the symbol using a linked list,
use list_for_each_entry() for iterating on the menus.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Currently, there is no direct link from (struct symbol) to (struct menu).
It is still possible to access associated menus through the P_SYMBOL
property, because property::menu is the relevant menu entry, but it
results in complex code, as seen in get_symbol_str().
Use a linked list for simpler traversal of relevant menus.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
When a checklist is opened, the cursor is rendered in a wrong position
(after the last list element on the screen). You can observe it by
opening any checklist in menuconfig.
Added wmove() to set the cursor in the proper position, just like in
menubox.c. Removed wnoutrefresh(dialog) because dialog window has
already been updated in print_buttons(). Replaced wnoutrefresh(list) and
doupdate() calls with one wrefresh(list) call.
Signed-off-by: Matthew Bystrin <dev.mbstr@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Use helper macros in hashtable.h for generic hashtable implementation.
We can git rid of the hash head index of for_all_symbols().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
for_all_symbols() iterates in the symbol hash table. The order of
iteration depends on the hash table implementation.
If you use it for printing errors, they are shown in random order.
For example, the order of following test input and the corresponding
error do not match:
- scripts/kconfig/tests/err_recursive_dep/Kconfig
- scripts/kconfig/tests/err_recursive_dep/expected_stderr
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Do not feed back the choice type to choice values.
Each choice value should explicitly specify 'bool' or 'tristate',
as all the Kconfig files already do. If the type were missing,
"config symbol defined without type" would be shown.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, a linked list is used to keep track of all the Kconfig
files that have ever been parsed. Every time the "source" statement
is encountered, the linked list is traversed to check if the file has
been opened before. This prevents the same file from being recorded
in include/config/auto.conf.cmd again.
Given 1500+ Kconfig files parsed, a hashtable is now a more optimal
data structure.
By the way, you may wonder why we check this in the first place.
It matters only when the same file is included multiple times.
In old days, such a use case was forbidden, but commit f094f8a1b2
("kconfig: allow multiple inclusion of the same file") provided a bit
more flexibility. Of course, it is almost hypothetical...
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Remove the 'static' qualifier from strhash() so that it can be accessed
from other files. Move it to util.c, which is a more appropriate location.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
To use ARRAY_SIZE from other files, move it to its own header,
just like include/linux/array_size.h.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Update the existing macros and inline functions based on
include/linux/list.h.
The variable name '_new' can be reverted to 'new' because this header
is no longer included from the C++ file, scripts/kconfig/qconf.cc.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The struct list_head is often embedded in other structures, while other
code is used in C functions.
By separating struct list_head into its own header, other headers are no
longer required to include the entire list.h.
This is similar to the kernel space, where struct list_head is defined
in <linux/types.h> instead of <linux/list.h>.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, file_lookup() returns a pointer to (struct file), but the
callers use only file->name.
Make it return the ->name member directly.
This adjustment encapsulates struct file and file_list as internal
implementation.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
struct file has two link nodes, 'next' and 'parent'.
The former is used to link files in the 'file_list' linked list,
which manages the list of Kconfig files seen so far.
The latter is used to link files in the 'current_file' linked list,
which manages the inclusion ("source") tree.
The latter should be tracked together with the lexer state.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, cur_filename is updated at the first token of each statement.
However, this seems unnecessary based on my understanding; the parser
can use the same variable as the lexer tracks.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
struct property is linked to struct file for diagnostic purposes.
It is always used to retrieve the file name through prop->file->name.
Associate struct property with the file name directly.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
struct menu is linked to struct file for diagnostic purposes.
It is always used to retrieve the file name through menu->file->name.
Associate struct menu with the file name directly.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Now zconf_curname() and zconf_lineno() are so simple that they just
return cur_filename, cur_lineno, respectively.
Remove these functions, and then use cur_filename and cur_lineno
directly.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Replace current_pos with separate variables representing the file name
and the line number, respectively.
No functional change is intended.
By the way, you might wonder why the "<none>" fallback exists in
zconf_curname(). menu_add_symbol() saves the current file and the line
number. It is intended to be called only during the yyparse() time.
However, menu_finalize() calls it, where there is no file being parsed.
This is a long-standing hack that should be fixed later. I left a FIXME
comment.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
These are needed only for the parse stage. Move the prototypes into
a separate header to make sure they are not used after that.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This allows preprocess.c to free up all of its resources when the parse
stage is finished. It also ensures conf_write_autoconf_cmd() produces
consistent results even if called multiple times for any reason.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, include/config/autoconf.cmd saves included Kconfig files in
reverse order. While this is not a big deal, it is inconsistent with
other *.cmd files generated by fixdep.
Output the included Kconfig files in the included order.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Commit 1a7a8c6fd8 ("kconfig: allow long lines in config file") added
a self-implemented getline() for better portability.
However, getline() is standardized [1] and already used in other programs
such as scripts/kallsyms.c.
Use getline() provided by libc.
[1]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/getdelim.html
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
yyerror() reports the line number of the next line.
This +1 adjustment was introduced more than 20 years ago [1]. At that
time, the line number was decremented then incremented back and forth.
The line number management was refactored in a more maintainable way.
Such compensation is no longer needed.
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=d4f8a4530eb07a1385fd17b0e62a7dce97486f49
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
A macro placed at the end of a file with no newline causes an infinite
loop.
[Test Kconfig]
$(info,hello)
\ No newline at end of file
I realized that flex-provided input() returns 0 instead of EOF when it
reaches the end of a file.
Fixes: 104daea149 ("kconfig: reference environment variables directly and remove 'option env='")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The error message shows a wrong line number if the 'source' directive
is wrapped to the following line.
[Test Code]
source \
"Kconfig"
This results in the following error message:
Recursive inclusion detected.
Inclusion path:
current file : Kconfig
included from: Kconfig:2
The correct message should be as follows:
Recursive inclusion detected.
Inclusion path:
current file : Kconfig
included from: Kconfig:1
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
In Kconfig, there is a stack to save the lexer state for each inclusion
level.
Currently, it operates as an empty stack, with the 'current_buf' always
pointing to an empty buffer. There is no need to preallocate the buffer.
Change it to a full stack.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Geert Uytterhoeven reported that commit 4e244c10ea ("kconfig: remove
unneeded symbol_empty variable") changed the default value of
CONFIG_LOG_CPU_MAX_BUF_SHIFT from 12 to 0.
As it turned out, this is an undefined behavior because sym_calc_value()
stopped setting the sym->curr.tri field for 'int', 'hex', and 'string'
symbols.
This commit restores the original behavior, where 'int', 'hex', 'string'
symbols are interpreted as false if used in boolean contexts.
CONFIG_LOG_CPU_MAX_BUF_SHIFT will default to 12 again, irrespective
of CONFIG_BASE_SMALL. Presumably, this is not the intended behavior,
as already reported [1], but this is another issue that should be
addressed by a separate patch.
[1]: https://lore.kernel.org/all/f6856be8-54b7-0fa0-1d17-39632bf29ada@oracle.com/
Fixes: 4e244c10ea ("kconfig: remove unneeded symbol_empty variable")
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Closes: https://lore.kernel.org/all/CAMuHMdWm6u1wX7efZQf=2XUAHascps76YQac6rdnQGhc8nop_Q@mail.gmail.com/
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
When KCONFIG_WERROR env variable is set treat unmet direct
symbol dependency as a terminal condition (error).
Suggested-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
When using a custom location for kernel config files this merge config
command fails as it doesn't use the configuration set with
KCONFIG_CONFIG.
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
menu_has_help() and menu_get_help() functions are only used within
menu_get_ext_help().
Squash them into menu_get_ext_help(). It revealed the if-conditional
in menu_get_help() was unneeded, as menu_has_help() has already checked
that menu->help is not NULL.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Isak Ellmer