kernel/linux.git/scripts/kconfig/lexer.l, branch v6.12.80

kbuild: split x*alloc() functions in kconfig to scripts/include/xalloc.h

2024-09-01T11:34:48+00:00

These functions will be useful for other host programs. Signed-off-by: Masahiro Yamada

kconfig: remove 'optional' property support

2024-05-02T10:48:26+00:00

The 'choice' statement is primarily used to exclusively select one option, but the 'optional' property allows all entries to be disabled. In the following example, both A and B can be disabled simultaneously: choice prompt "choose A, B, or nothing" optional config A bool "A" config B bool "B" endchoice You can achieve the equivalent outcome by other means. A common solution is to add another option to guard the choice block. In the following example, you can set ENABLE_A_B_CHOICE=n to disable the entire choice block: choice prompt "choose A or B" depends on ENABLE_A_B_CHOICE config A bool "A" config B bool "B" endchoice Another approach is to insert one more entry: choice prompt "choose A, B, or disable both" config A bool "A" config B bool "B" config DISABLE_A_AND_B bool "choose this to disable both A and B" endchoice Some real examples are DEBUG_INFO_NONE, INITRAMFS_COMPRESSION_NONE, LTO_NONE, etc. The 'optional' property is even more unnecessary for a tristate choice. Without the 'optional' property, you can disable A and B; you can set 'm' in the choice prompt, and disable A and B individually: choice prompt "choose one built-in or make them modular" config A tristate "A" config B tristate "B" endchoice In conclusion, the 'optional' property was unneeded. Signed-off-by: Masahiro Yamada Reviewed-by: Nicolas Schier

kconfig: change file_lookup() to return the file name

2024-02-19T09:20:41+00:00

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

kconfig: move the file and lineno in struct file to struct buffer

2024-02-19T09:20:40+00:00

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

kconfig: replace remaining current_file->name with cur_filename

2024-02-19T09:20:40+00:00

Replace the remaining current_file->name in the lexer context. Signed-off-by: Masahiro Yamada

kconfig: do not delay the cur_filename update

2024-02-19T09:20:40+00:00

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

kconfig: replace file->name with name in zconf_nextfile()

2024-02-19T09:20:40+00:00

The 'file->name' and 'name' are the same in this function. Signed-off-by: Masahiro Yamada

kconfig: remove zconf_curname() and zconf_lineno()

2024-02-19T09:20:40+00:00

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

kconfig: replace current_pos with separate cur_{filename,lineno}

2024-02-19T09:20:40+00:00

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 "" 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

kconfig: split preprocessor prototypes into preprocess.h

2024-02-19T09:20:40+00:00

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