In my understanding, special characters such as '.' and '/' are
supported in unquoted words to use bare file paths in the "source"
statement.
With the previous commit surrounding all file paths with double
quotes, we can drop this.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
There is no grammatical ambiguity by using T_WORD for variables.
The parser can distinguish variables from symbols from the context.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, the lexer returns T_ASSIGN for all of =, :=, and +=
associating yylval with the flavor.
I want to make the generated lexer as simple as possible. So, the
lexer should convert keywords to tokens without thinking about the
meaning.
= -> T_EQUAL
:= -> T_COLON_EQUAL
+= -> T_PLUS_EQUAL
Unfortunately, Kconfig uses = instead of == for the equal operator.
So, the same token T_EQUAL is used for assignment and comparison.
The parser can still distinguish them from the context.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
For the keywords "modules", "defconfig_list", and "allnoconfig_y",
the lexer should pass specific tokens instead of generic T_WORD.
This simplifies both the lexer and the parser.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This commit removes kconf_id::stype to prepare for the entire
removal of kconf_id.c
To simplify the lexer, I want keywords straight-mapped to tokens.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The LLVM/Clang project provides many tools for analyzing C source code.
Many of these tools are based on LibTooling
(https://clang.llvm.org/docs/LibTooling.html), which depends on a
database of compiler flags. The standard container for this database is
compile_commands.json, which consists of a list of JSON objects, each
with "directory", "file", and "command" fields.
Some build systems, like cmake or bazel, produce this compilation
information directly. Naturally, Makefiles don't. However, the kernel
makefiles already create .<target>.o.cmd files that contain all the
information needed to build a compile_commands.json file.
So, this commit adds scripts/gen_compile_commands.py, which recursively
searches through a directory for .<target>.o.cmd files and extracts
appropriate compile commands from them. It writes a
compile_commands.json file that LibTooling-based tools can use.
By default, gen_compile_commands.py starts its search in its working
directory and (over)writes compile_commands.json in the working
directory. However, it also supports --output and --directory flags for
out-of-tree use.
Note that while gen_compile_commands.py enables the use of clang-based
tools, it does not require the kernel to be compiled with clang. E.g.,
the following sequence of commands produces a compile_commands.json file
that works correctly with LibTooling.
make defconfig
make
scripts/gen_compile_commands.py
Also note that this script is written to work correctly in both Python 2
and Python 3, so it does not specify the Python version in its first
line.
For an example of the utility of this script: after running
gen_compile_commands.json on the latest kernel version, I was able to
use Vim + the YouCompleteMe pluging + clangd to automatically jump to
definitions and declarations. Obviously, cscope and ctags provide some
of this functionality; the advantage of supporting LibTooling is that it
opens the door to many other clang-based tools that understand the code
directly and do not rely on regular expressions and heuristics.
Tested: Built several recent kernel versions and ran the script against
them, testing tools like clangd (for editor/LSP support) and clang-check
(for static analysis). Also extracted some test .cmd files from a kernel
build and wrote a test script to check that the script behaved correctly
with all permutations of the --output and --directory flags.
Signed-off-by: Tom Roeder <tmroeder@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
"Assignment" requires the assigned value before the place that
value is stored into.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Some code may overall use 0 and 1, so don't introduce occasional
uses of true and false in these cases.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
part-of-module and quiet_modtag are set for the same targets.
Define quiet_modtag based on part-of-module.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
All objects in $(obj-m) are contained in $(real-obj-m) as well.
It is true composite objects are only contained in $(obj-m),
but [M] is hard-coded in quiet_cmd_link_multi-m.
This line is redundant.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
- Use conventional $(MAKE) $(asm-generic)=<dir> style
for directory descending
- Remove unneeded FORCE since "all" is a phony target
- Remove unneeded "_dummy :=" assignment
- Skip $(shell mkdir ...) when headers exist in the directory
- Misc cleanups
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Currently, "visible" and "depends on", if defined in a menu entry,
must appear in that order.
The real example is in drivers/media/tuners/Kconfig:
menu "Customize TV tuners"
visible if <expr1>
depends on <expr2>
... is fine, but you cannot change the property order like this:
menu "Customize TV tuners"
depends on <expr2>
visible if <expr1>
Kconfig does not require a specific order of properties. In this case,
menu_add_visibility(() and menu_add_dep() are orthogonal.
Loosen this unreasonable restriction.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The code block surrounded by "menu" ... "endmenu" is stmt_list.
Remove the redundant menu_block symbol entirely.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The code block surrounded by "if" ... "endif" is stmt_list.
Remove the redundant if_block symbol entirely.
Remove "stmt_list: stmt_list end" rule as well since it would
obviously cause conflicts.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This commit decreases 6 shift/reduce conflicts, and finally achieves
conflict-free parser.
Since Kconfig has no terminator for a config block, detecting the end
of config_stmt is not easy.
For example, there are two ways for handling the error in the following
code:
1 config FOO
2 =
[A] Print "unknown option" error, assuming the line 2 is a part of
config_option_list
[B] Print "invalid statement", assuming the line 1 is reduced into
a config_stmt by itself
Bison actually chooses [A] because it performs the shift rather than
the reduction where both are possible.
However, there is no reason to choose one over the other.
Let's remove the option_error, and let it fall back to [B].
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This commit decreases 15 shift/reduce conflicts.
The location of this error recovery is ambiguous.
For example, there are two ways to interpret the following code:
1 config FOO
2 bool "foo"
[A] Both lines are reduced together into a config_stmt.
[B] The only line 1 is reduced into a config_stmt, and the line 2
matches to "option_name error T_EOL"
Of course, we expect [A], but [B] could be grammatically possible.
Kconfig has no terminator for a config block. So, we cannot detect its
end until we see a non-property keyword. People often insert a blank
line between two config blocks, but it is just a coding convention.
Blank lines are actually allowed anywhere in Kconfig files.
The real error is when a property keyword appears right after "endif",
"endchoice", "endmenu", "source", "comment", or variable assignment.
Instead of fixing the grammatical ambiguity, I chose to simply remove
this error recovery.
The difference is
unexpected option "bool"
... is turned into a more generic message:
invalid statement
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
It would be nice to warn if a new line is missing at end of file.
We could do this by checkpatch.pl for arbitrary files, but new line
is rather essential as a statement terminator in Kconfig.
The warning message looks like this:
kernel/Kconfig.preempt:60:warning: no new line at end of file
Currently, kernel/Kconfig.preempt is the only file with no new line
at end of file. Fix it.
I know there are some false negative cases. For example, no warning
is displayed when the last line contains some whitespaces/comments,
but no new line. Yet, this commit works well for most cases.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
There is actually a space after "sp," like this,
ffff2000080813c8: a9bb7bfd stp x29, x30, [sp, #-80]!
Right now, checkstack.pl isn't able to print anything on aarch64,
because it won't be able to match the stating objdump line of a function
due to this missing space. Hence, it displays every stack as zero-size.
After this patch, checkpatch.pl is able to match the start of a
function's objdump, and is then able to calculate each function's stack
correctly.
Link: http://lkml.kernel.org/r/20181207195843.38528-1-cai@lca.pw
Signed-off-by: Qian Cai <cai@lca.pw>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Masahiro Yamada
Tom Roeder
Ingo Molnar
Julia Lawall
Thierry Reding
Qian Cai
Rob Herring