kbuild: Create intermediate vmlinux build with relocations preserved

The imperative paradigm used to build vmlinux, extract some info from it
or perform some checks on it, and subsequently modify it

kbuild: Create intermediate vmlinux build with relocations preserved

The imperative paradigm used to build vmlinux, extract some info from it
or perform some checks on it, and subsequently modify it again goes
against the declarative paradigm that is usually employed for defining
make rules.

In particular, the Makefile.postlink files that consume their input via
an output rule result in some dodgy logic in the decompressor makefiles
for RISC-V and x86, given that the vmlinux.relocs input file needed to
generate the arch-specific relocation tables may not exist or be out of
date, but cannot be constructed using the ordinary Make dependency based
rules, because the info needs to be extracted while vmlinux is in its
ephemeral, non-stripped form.

So instead, for architectures that require the static relocations that
are emitted into vmlinux when passing --emit-relocs to the linker, and
are subsequently stripped out again, introduce an intermediate vmlinux
target called vmlinux.unstripped, and organize the reset of the build
logic accordingly:

- vmlinux.unstripped is created only once, and not updated again
- build rules under arch/*/boot can depend on vmlinux.unstripped without
running the risk of the data disappearing or being out of date
- the final vmlinux generated by the build is not bloated with static
relocations that are never needed again after the build completes.

Signed-off-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

rust: use host dylib naming convention to support macOS

Because the `macros` crate exposes procedural macros, it must be
compiled as a dynamic library (so it can be loaded by the compiler at
compile

rust: use host dylib naming convention to support macOS

Because the `macros` crate exposes procedural macros, it must be
compiled as a dynamic library (so it can be loaded by the compiler at
compile-time).

Before this change the resulting artifact was always named
`libmacros.so`, which works on hosts where this matches the naming
convention for dynamic libraries. However the proper name on macOS would
be `libmacros.dylib`.

This turns out to matter even when the dependency is passed with a path
(`--extern macros=path/to/libmacros.so` rather than `--extern macros`)
because rustc uses the file name to infer the type of the library (see
link). This is because there's no way to specify both the path to and
the type of the external library via CLI flags. The compiler could
speculatively parse the file to determine its type, but it does not do
so today.

This means that libraries that match neither rustc's naming convention
for static libraries nor the platform's naming convention for dynamic
libraries are *rejected*.

The only solution I've found is to follow the host platform's naming
convention. This patch does that by querying the compiler to determine
the appropriate name for the artifact. This allows the kernel to build
with CONFIG_RUST=y on macOS.

Link: https://github.com/rust-lang/rust/blob/d829780/compiler/rustc_metadata/src/locator.rs#L728-L752
Tested-by: Daniel Gomez <[email protected]>
Co-developed-by: Fiona Behrens <[email protected]>
Signed-off-by: Fiona Behrens <[email protected]>
Signed-off-by: Tamir Duberstein <[email protected]>
Tested-by: Andreas Hindborg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Added `MAKEFLAGS=`s to avoid jobserver warnings. Removed space.
Reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

gitignore: Don't ignore 'tags' directory

W=1 builds reported warnings regarding files being ignored:
tools/testing/selftests/arm64/tags/.gitignore: warning: ignored by one of the .gitignore files

gitignore: Don't ignore 'tags' directory

W=1 builds reported warnings regarding files being ignored:
tools/testing/selftests/arm64/tags/.gitignore: warning: ignored by one of the .gitignore files
tools/testing/selftests/arm64/tags/Makefile: warning: ignored by one of the .gitignore files
tools/testing/selftests/arm64/tags/tags_test.c: warning: ignored by one of the .gitignore files

Adjusting the .gitignore entries will prevent these warnings and
ensure a smoother script execution.

Reported-by: kernel test robot <[email protected]>
Signed-off-by: Li Zhijian <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

rust: introduce `.clippy.toml`

Some Clippy lints can be configured/tweaked. We will use these knobs to
our advantage in later commits.

This is done via a configuration file, `.clippy.toml` [1]. The

rust: introduce `.clippy.toml`

Some Clippy lints can be configured/tweaked. We will use these knobs to
our advantage in later commits.

This is done via a configuration file, `.clippy.toml` [1]. The file is
currently unstable. This may be a problem in the future, but we can adapt
as needed. In addition, we proposed adding Clippy to the Rust CI's RFL
job [2], so we should be able to catch issues pre-merge.

Thus introduce the file.

Link: https://doc.rust-lang.org/clippy/configuration.html [1]
Link: https://github.com/rust-lang/rust/pull/128928 [2]
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Trevor Gross <[email protected]>
Tested-by: Gary Guo <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

kbuild: generate offset range data for builtin modules

Create file module.builtin.ranges that can be used to find where
built-in modules are located by their addresses. This will be useful for
traci

kbuild: generate offset range data for builtin modules

Create file module.builtin.ranges that can be used to find where
built-in modules are located by their addresses. This will be useful for
tracing tools to find what functions are for various built-in modules.

The offset range data for builtin modules is generated using:
- modules.builtin: associates object files with module names
- vmlinux.map: provides load order of sections and offset of first member
per section
- vmlinux.o.map: provides offset of object file content per section
- .*.cmd: build cmd file with KBUILD_MODFILE

The generated data will look like:

.text 00000000-00000000 = _text
.text 0000baf0-0000cb10 amd_uncore
.text 0009bd10-0009c8e0 iosf_mbi
...
.text 00b9f080-00ba011a intel_skl_int3472_discrete
.text 00ba0120-00ba03c0 intel_skl_int3472_discrete intel_skl_int3472_tps68470
.text 00ba03c0-00ba08d6 intel_skl_int3472_tps68470
...
.data 00000000-00000000 = _sdata
.data 0000f020-0000f680 amd_uncore

For each ELF section, it lists the offset of the first symbol. This can
be used to determine the base address of the section at runtime.

Next, it lists (in strict ascending order) offset ranges in that section
that cover the symbols of one or more builtin modules. Multiple ranges
can apply to a single module, and ranges can be shared between modules.

The CONFIG_BUILTIN_MODULE_RANGES option controls whether offset range data
is generated for kernel modules that are built into the kernel image.

How it works:

1. The modules.builtin file is parsed to obtain a list of built-in
module names and their associated object names (the .ko file that
the module would be in if it were a loadable module, hereafter
referred to as <kmodfile>). This object name can be used to
identify objects in the kernel compile because any C or assembler
code that ends up into a built-in module will have the option
-DKBUILD_MODFILE=<kmodfile> present in its build command, and those
can be found in the .<obj>.cmd file in the kernel build tree.

If an object is part of multiple modules, they will all be listed
in the KBUILD_MODFILE option argument.

This allows us to conclusively determine whether an object in the
kernel build belong to any modules, and which.

2. The vmlinux.map is parsed next to determine the base address of each
top level section so that all addresses into the section can be
turned into offsets. This makes it possible to handle sections
getting loaded at different addresses at system boot.

We also determine an 'anchor' symbol at the beginning of each
section to make it possible to calculate the true base address of
a section at runtime (i.e. symbol address - symbol offset).

We collect start addresses of sections that are included in the top
level section. This is used when vmlinux is linked using vmlinux.o,
because in that case, we need to look at the vmlinux.o linker map to
know what object a symbol is found in.

And finally, we process each symbol that is listed in vmlinux.map
(or vmlinux.o.map) based on the following structure:

vmlinux linked from vmlinux.a:

vmlinux.map:
<top level section>
<included section> -- might be same as top level section)
<object> -- built-in association known
<symbol> -- belongs to module(s) object belongs to
...

vmlinux linked from vmlinux.o:

vmlinux.map:
<top level section>
<included section> -- might be same as top level section)
vmlinux.o -- need to use vmlinux.o.map
<symbol> -- ignored
...

vmlinux.o.map:
<section>
<object> -- built-in association known
<symbol> -- belongs to module(s) object belongs to
...

3. As sections, objects, and symbols are processed, offset ranges are
constructed in a straight-forward way:

- If the symbol belongs to one or more built-in modules:
- If we were working on the same module(s), extend the range
to include this object
- If we were working on another module(s), close that range,
and start the new one
- If the symbol does not belong to any built-in modules:
- If we were working on a module(s) range, close that range

Signed-off-by: Kris Van Hees <[email protected]>
Reviewed-by: Nick Alcock <[email protected]>
Reviewed-by: Alan Maguire <[email protected]>
Reviewed-by: Steven Rostedt (Google) <[email protected]>
Tested-by: Sam James <[email protected]>
Reviewed-by: Sami Tolvanen <[email protected]>
Tested-by: Sami Tolvanen <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: remove *.symversions left-over

Commit 5ce2176b81f7 ("genksyms: adjust the output format to modpost")
stopped generating *.symversions files.

Remove the left-over from the .gitignore file an

kbuild: remove *.symversions left-over

Commit 5ce2176b81f7 ("genksyms: adjust the output format to modpost")
stopped generating *.symversions files.

Remove the left-over from the .gitignore file and the 'clean' rule.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>

show more ...

Remove *.orig pattern from .gitignore

Commit 3f1b0e1f2875 (".gitignore update") added *.orig and *.rej
patterns to .gitignore in v2.6.23. The commit message didn't give a
rationale. Later on, commit

Remove *.orig pattern from .gitignore

Commit 3f1b0e1f2875 (".gitignore update") added *.orig and *.rej
patterns to .gitignore in v2.6.23. The commit message didn't give a
rationale. Later on, commit 1f5d3a6b6532 ("Remove *.rej pattern from
.gitignore") removed the *.rej pattern in v2.6.26, on the rationale that
*.rej files indicated something went really wrong and should not be
ignored.

The *.rej files are now shown by `git status`, which helps located
conflicts when applying patches and lowers the probability that they
will go unnoticed. It is however still easy to overlook the *.orig files
which slowly polute the source tree. That's not as big of a deal as not
noticing a conflict, but it's still not nice.

Drop the *.orig pattern from .gitignore to avoid this and help keep the
source tree clean.

Signed-off-by: Laurent Pinchart <[email protected]>
[[email protected]:
I do not have a strong opinion about this. Perhaps some people may have
a different opinion.

If you are someone who wants to ignore *.orig, it is likely you would
want to do so across all projects. Then, $XDG_CONFIG_HOME/git/ignore
would be more suitable for your needs. gitignore(5) suggests, "Patterns
which a user wants Git to ignore in all situations generally go into a
file specified by core.excludesFile in the user's ~/.gitconfig".

Please note that you cannot do the opposite; if *.orig is ignored by
the project's .gitignore, you cannot override the decision because
$XDG_CONFIG_HOME/git/ignore has a lower priority.

If *.orig is sitting on the fence, I'd leave it to the users. ]
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

.gitignore: add .gcda files

These files contain the runtime coverage data generated by gcov.

Signed-off-by: Vegard Nossum <[email protected]>
Signed-off-by: Chuck Lever <[email protected]

.gitignore: add .gcda files

These files contain the runtime coverage data generated by gcov.

Signed-off-by: Vegard Nossum <[email protected]>
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Allison Henderson <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

kbuild: add script and target to generate pacman package

pacman is the package manager used by Arch Linux and its derivates.
Creating native packages from the kernel tree has multiple advantages:

*

kbuild: add script and target to generate pacman package

pacman is the package manager used by Arch Linux and its derivates.
Creating native packages from the kernel tree has multiple advantages:

* The package triggers the correct hooks for initramfs generation and
bootloader configuration
* Uninstallation is complete and also invokes the relevant hooks
* New UAPI headers can be installed without any manual bookkeeping

The PKGBUILD file is a modified version of the one used for the
downstream Arch Linux "linux" package.
Extra steps that should not be necessary for a development kernel have
been removed and an UAPI header package has been added.

Signed-off-by: Thomas Weißschuh <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Tested-by: Nathan Chancellor <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: create a list of all built DTB files

It is useful to have a list of all *.dtb and *.dtbo files generated
from the current build.

With this commit, 'make dtbs' creates arch/*/boot/dts/dtbs-l

kbuild: create a list of all built DTB files

It is useful to have a list of all *.dtb and *.dtbo files generated
from the current build.

With this commit, 'make dtbs' creates arch/*/boot/dts/dtbs-list, which
lists the dtb(o) files created in the current build. It maintains the
order of the dtb-y additions in Makefiles although the order is not
important for DTBs. It is a (good) side effect through the reuse of the
modules.order rule.

Please note this list only includes the files directly added to dtb-y.

For example, consider this case:

foo-dtbs := foo_base.dtb foo_overlay.dtbo
dtb-y := foo.dtb

In this example, the list will include foo.dtb, but not foo_base.dtb
or foo_overlay.dtbo.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

Add .editorconfig file for basic formatting

EditorConfig is a specification to define the most basic code formatting
stuff, and it's supported by many editors and IDEs, either directly or
via plugin

Add .editorconfig file for basic formatting

EditorConfig is a specification to define the most basic code formatting
stuff, and it's supported by many editors and IDEs, either directly or
via plugins, including VSCode/VSCodium, Vim, emacs and more.

It allows to define formatting style related to indentation, charset,
end of lines and trailing whitespaces. It also allows to apply different
formats for different files based on wildcards, so for example it is
possible to apply different configs to *.{c,h}, *.py and *.rs.

In linux project, defining a .editorconfig might help to those people
that work on different projects with different indentation styles, so
they cannot define a global style. Now they will directly see the
correct indentation on every fresh clone of the project.

See https://editorconfig.org

Co-developed-by: Danny Lin <[email protected]>
Signed-off-by: Danny Lin <[email protected]>
Signed-off-by: Íñigo Huguet <[email protected]>
Acked-by: Mickaël Salaün <[email protected]>
Reviewed-by: Vincent Mailhol <[email protected]>
Tested-by: Vincent Mailhol <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: rpm-pkg: generate kernel.spec in rpmbuild/SPECS/

kernel.spec is the last piece that resides outside the rpmbuild/
directory. Move all the RPM-related files to rpmbuild/ consistently.

Signed

kbuild: rpm-pkg: generate kernel.spec in rpmbuild/SPECS/

kernel.spec is the last piece that resides outside the rpmbuild/
directory. Move all the RPM-related files to rpmbuild/ consistently.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Tested-by: Nathan Chancellor <[email protected]>

show more ...

kbuild: rpm-pkg: rename binkernel.spec to kernel.spec

Now kernel.spec and binkernel.spec have the exactly same contents.

Use kernel.spec for binrpm-pkg as well.

Signed-off-by: Masahiro Yamada <mas

kbuild: rpm-pkg: rename binkernel.spec to kernel.spec

Now kernel.spec and binkernel.spec have the exactly same contents.

Use kernel.spec for binrpm-pkg as well.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

Revert ".gitignore: ignore *.cover and *.mbx"

This reverts commit 534066a983df0935847061c844eb178f8a53a9e7.

It's actively detrimental in that it hides files that shouldn't be
hidden.

If I have som

Revert ".gitignore: ignore *.cover and *.mbx"

This reverts commit 534066a983df0935847061c844eb178f8a53a9e7.

It's actively detrimental in that it hides files that shouldn't be
hidden.

If I have some b4 mbx file in my git directory, it either was already
applied with "git am" and is now stale, or maybe it's waiting for that
to happen. In neither case is "ignore it" the right option.

Signed-off-by: Linus Torvalds <[email protected]>

show more ...

kbuild: implement CONFIG_TRIM_UNUSED_KSYMS without recursion

When CONFIG_TRIM_UNUSED_KSYMS is enabled, Kbuild recursively traverses
the directory tree to determine which EXPORT_SYMBOL to trim. If an

kbuild: implement CONFIG_TRIM_UNUSED_KSYMS without recursion

When CONFIG_TRIM_UNUSED_KSYMS is enabled, Kbuild recursively traverses
the directory tree to determine which EXPORT_SYMBOL to trim. If an
EXPORT_SYMBOL turns out to be unused by anyone, Kbuild begins the
second traverse, where some source files are recompiled with their
EXPORT_SYMBOL() tuned into a no-op.

Linus stated negative opinions about this slowness in commits:

- 5cf0fd591f2e ("Kbuild: disable TRIM_UNUSED_KSYMS option")
- a555bdd0c58c ("Kbuild: enable TRIM_UNUSED_KSYMS again, with some guarding")

We can do this better now. The final data structures of EXPORT_SYMBOL
are generated by the modpost stage, so modpost can selectively emit
KSYMTAB entries that are really used by modules.

Commit f73edc8951b2 ("kbuild: unify two modpost invocations") is another
ground-work to do this in a one-pass algorithm. With the list of modules,
modpost sets sym->used if it is used by a module. modpost emits KSYMTAB
only for symbols with sym->used==true.

BTW, Nicolas explained why the trimming was implemented with recursion:

https://lore.kernel.org/all/[email protected]/

Actually, we never achieved that level of optimization where the chain
reaction of trimming comes into play because:

- CONFIG_LTO_CLANG cannot remove any unused symbols
- CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is enabled only for vmlinux,
but not modules

If deeper trimming is required, we need to revisit this, but I guess
that is unlikely to happen.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

.gitignore: Do not ignore .kunitconfig files

Circumvent the .gitignore wildcard to avoid warnings about ignored
.kunitconfig files. As far as I can tell, the warnings are harmless
and these files ar

.gitignore: Do not ignore .kunitconfig files

Circumvent the .gitignore wildcard to avoid warnings about ignored
.kunitconfig files. As far as I can tell, the warnings are harmless
and these files are not actually ignored.

Reported-by: kernel test robot <[email protected]>
Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>

show more ...

.gitignore: Unignore .kunitconfig

There are almost dozen of .kunitconfig files that are ignored but
tracked. Unignore them.

Signed-off-by: Andy Shevchenko <[email protected]>
Review

.gitignore: Unignore .kunitconfig

There are almost dozen of .kunitconfig files that are ignored but
tracked. Unignore them.

Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: David Gow <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

kbuild: rpm-pkg: move source components to rpmbuild/SOURCES

Prepare to add more files to the source RPM.

Also, fix the build error when KCONFIG_CONFIG is set:
error: Bad file: ./.config: No such

kbuild: rpm-pkg: move source components to rpmbuild/SOURCES

Prepare to add more files to the source RPM.

Also, fix the build error when KCONFIG_CONFIG is set:
error: Bad file: ./.config: No such file or directory

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

.gitignore: ignore *.cover and *.mbx

The 'b4' command creates a *.mbx file, and also a *.cover file if the
patch set has a cover-letter. Ignore them.

Signed-off-by: Masahiro Yamada <masahiroy@kerne

.gitignore: ignore *.cover and *.mbx

The 'b4' command creates a *.mbx file, and also a *.cover file if the
patch set has a cover-letter. Ignore them.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>

show more ...

.gitignore: update the command to check tracked files being ignored

Recent git versions do not accept the noted command.

$ git ls-files -i --exclude-standard
fatal: ls-files -i must be used wit

.gitignore: update the command to check tracked files being ignored

Recent git versions do not accept the noted command.

$ git ls-files -i --exclude-standard
fatal: ls-files -i must be used with either -o or -c

The -c was implied before, but we need to make it explicit since
git commit b338e9f66873 ("ls-files: error out on -i unless -o or -c
are specified").

Also, replace --exclude-standard with --exclude-per-directory=.gitignore
so that everyone will get consistent results.

git-ls-files(1) says:

--exclude-standard
Add the standard Git exclusions: .git/info/exclude, .gitignore in
each directory, and the user's global exclusion file.

We cannot predict what is locally added to .git/info/exclude or the
user's global exclusion file.

We can only manage .gitignore files committed to the repository.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Miguel Ojeda <[email protected]>

show more ...

.gitignore: ignore *.rpm

Previously, *.rpm files were created under $HOME/rpmbuild/, but since
commit 8818039f959b ("kbuild: add ability to make source rpm buildable
using koji"), srcrpm-pkg creates

.gitignore: ignore *.rpm

Previously, *.rpm files were created under $HOME/rpmbuild/, but since
commit 8818039f959b ("kbuild: add ability to make source rpm buildable
using koji"), srcrpm-pkg creates the source rpm in the kernel tree
because it sets '_srcrpmdir'.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: Cleanup DT Overlay intermediate files as appropriate

%.dtbo.o and %.dtbo.S files are used to build-in DT Overlay. They should
should not be removed by Make or the kernel will be needlessly r

kbuild: Cleanup DT Overlay intermediate files as appropriate

%.dtbo.o and %.dtbo.S files are used to build-in DT Overlay. They should
should not be removed by Make or the kernel will be needlessly rebuilt.

These should be removed by "clean" and ignored by git like other
intermediate files.

Reported-by: Andy Shevchenko <[email protected]>
Signed-off-by: Andrew Davis <[email protected]>
Fixes: 941214a512d8 ("kbuild: Allow DTB overlays to built into .dtbo.S files")
Tested-by: Andy Shevchenko <[email protected]>
Acked-by: Masahiro Yamada <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rob Herring <[email protected]>

show more ...

Kbuild: add Rust support

Having most of the new files in place, we now enable Rust support
in the build system, including `Kconfig` entries related to Rust,
the Rust configuration printer and a few

Kbuild: add Rust support

Having most of the new files in place, we now enable Rust support
in the build system, including `Kconfig` entries related to Rust,
the Rust configuration printer and a few other bits.

Reviewed-by: Kees Cook <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Tested-by: Nick Desaulniers <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Co-developed-by: Alex Gaynor <[email protected]>
Signed-off-by: Alex Gaynor <[email protected]>
Co-developed-by: Finn Behrens <[email protected]>
Signed-off-by: Finn Behrens <[email protected]>
Co-developed-by: Adam Bratschi-Kaye <[email protected]>
Signed-off-by: Adam Bratschi-Kaye <[email protected]>
Co-developed-by: Wedson Almeida Filho <[email protected]>
Signed-off-by: Wedson Almeida Filho <[email protected]>
Co-developed-by: Michael Ellerman <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Co-developed-by: Sven Van Asbroeck <[email protected]>
Signed-off-by: Sven Van Asbroeck <[email protected]>
Co-developed-by: Gary Guo <[email protected]>
Signed-off-by: Gary Guo <[email protected]>
Co-developed-by: Boris-Chengbiao Zhou <[email protected]>
Signed-off-by: Boris-Chengbiao Zhou <[email protected]>
Co-developed-by: Boqun Feng <[email protected]>
Signed-off-by: Boqun Feng <[email protected]>
Co-developed-by: Douglas Su <[email protected]>
Signed-off-by: Douglas Su <[email protected]>
Co-developed-by: Dariusz Sosnowski <[email protected]>
Signed-off-by: Dariusz Sosnowski <[email protected]>
Co-developed-by: Antonio Terceiro <[email protected]>
Signed-off-by: Antonio Terceiro <[email protected]>
Co-developed-by: Daniel Xu <[email protected]>
Signed-off-by: Daniel Xu <[email protected]>
Co-developed-by: Björn Roy Baron <[email protected]>
Signed-off-by: Björn Roy Baron <[email protected]>
Co-developed-by: Martin Rodriguez Reboredo <[email protected]>
Signed-off-by: Martin Rodriguez Reboredo <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: add `.rustfmt.toml`

This is the configuration file for the `rustfmt` tool.

`rustfmt` is a tool for formatting Rust code according to style guidelines.
It is very commonly used across Rust pro

rust: add `.rustfmt.toml`

This is the configuration file for the `rustfmt` tool.

`rustfmt` is a tool for formatting Rust code according to style guidelines.
It is very commonly used across Rust projects.

The default configuration options are used.

Reviewed-by: Kees Cook <[email protected]>
Co-developed-by: Alex Gaynor <[email protected]>
Signed-off-by: Alex Gaynor <[email protected]>
Co-developed-by: Wedson Almeida Filho <[email protected]>
Signed-off-by: Wedson Almeida Filho <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

scripts: add `generate_rust_analyzer.py`

The `generate_rust_analyzer.py` script generates the configuration
file (`rust-project.json`) for rust-analyzer.

rust-analyzer is a modular compiler fronten

scripts: add `generate_rust_analyzer.py`

The `generate_rust_analyzer.py` script generates the configuration
file (`rust-project.json`) for rust-analyzer.

rust-analyzer is a modular compiler frontend for the Rust language.
It provides an LSP server which can be used in editors such as
VS Code, Emacs or Vim.

Reviewed-by: Kees Cook <[email protected]>
Co-developed-by: Alex Gaynor <[email protected]>
Signed-off-by: Alex Gaynor <[email protected]>
Co-developed-by: Finn Behrens <[email protected]>
Signed-off-by: Finn Behrens <[email protected]>
Co-developed-by: Wedson Almeida Filho <[email protected]>
Signed-off-by: Wedson Almeida Filho <[email protected]>
Co-developed-by: Gary Guo <[email protected]>
Signed-off-by: Gary Guo <[email protected]>
Co-developed-by: Boris-Chengbiao Zhou <[email protected]>
Signed-off-by: Boris-Chengbiao Zhou <[email protected]>
Co-developed-by: Björn Roy Baron <[email protected]>
Signed-off-by: Björn Roy Baron <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...