Searched +hist:17 +hist:d857be (Results 1 - 1 of 1) sorted by relevance
/linux-master/ | ||
H A D | Makefile | diff ecab4115 Fri Feb 16 17:26:37 MST 2024 Miguel Ojeda <ojeda@kernel.org> kbuild: mark `rustc` (and others) invocations as recursive `rustc` (like Cargo) may take advantage of the jobserver at any time (e.g. for backend parallelism, or eventually frontend too). In the kernel, we call `rustc` with `-Ccodegen-units=1` (and `-Zthreads` is 1 so far), so we do not expect parallelism. However, in the upcoming Rust 1.76.0, a warning is emitted by `rustc` [1] when it cannot connect to the jobserver it was passed (in many cases, but not all: compiling and `--print sysroot` do, but `--version` does not). And given GNU Make always passes the jobserver in the environment variable (even when a line is deemed non-recursive), `rustc` will end up complaining about it (in particular in Make 4.3 where there is only the simple pipe jobserver style). One solution is to remove the jobserver from `MAKEFLAGS`. However, we can mark the lines with calls to `rustc` (and Cargo) as recursive, which looks simpler. This is being documented as a recommendation in `rustc` [2] and allows us to be ready for the time we may use parallelism inside `rustc` (potentially now, if a user passes `-Zthreads`). Thus do so. Similarly, do the same for `rustdoc` and `cargo` calls. Finally, there is one case that the solution does not cover, which is the `$(shell ...)` call we have. Thus, for that one, set an empty `MAKEFLAGS` environment variable. Link: https://github.com/rust-lang/rust/issues/120515 [1] Acked-by: Masahiro Yamada <masahiroy@kernel.org> Link: https://github.com/rust-lang/rust/pull/121564 [2] Link: https://lore.kernel.org/r/20240217002638.57373-1-ojeda@kernel.org [ Reworded to add link to PR documenting the recommendation. ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> diff 54be6c6c Sat Feb 03 17:20:36 MST 2024 Linus Torvalds <torvalds@linux-foundation.org> Linux 6.8-rc3 diff 113a6186 Tue Oct 31 17:50:11 MDT 2023 Gustavo A. R. Silva <gustavoars@kernel.org> Makefile: Enable -Wstringop-overflow globally It seems that we have finished addressing all the remaining issues regarding -Wstringop-overflow. So, we are now in good shape to enable this compiler option globally. Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> diff 861deac3 Sat Dec 23 17:25:56 MST 2023 Linus Torvalds <torvalds@linux-foundation.org> Linux 6.7-rc7 diff ceb6a6f0 Sun Dec 17 16:19:28 MST 2023 Linus Torvalds <torvalds@linux-foundation.org> Linux 6.7-rc6 diff b85ea95d Sun Nov 12 17:19:07 MST 2023 Linus Torvalds <torvalds@linux-foundation.org> Linux 6.7-rc1 diff ce9ecca0 Sun Sep 17 15:40:24 MDT 2023 Linus Torvalds <torvalds@linux-foundation.org> Linux 6.6-rc2 diff 0bb80ecc Sun Sep 10 17:28:41 MDT 2023 Linus Torvalds <torvalds@linux-foundation.org> Linux 6.6-rc1 diff 9418e686 Sat Jul 29 16:03:17 MDT 2023 Miguel Ojeda <ojeda@kernel.org> rust: enable `no_mangle_with_rust_abi` Clippy lint Introduced in Rust 1.69.0 [1], this lint prevents forgetting to set the C ABI when using `#[no_mangle]` (or thinking it is implied). For instance, it would have prevented the issue [2] fixed by commit c682e4c37d2b ("rust: kernel: Mark rust_fmt_argument as extern "C""). error: `#[no_mangle]` set on a function with the default (`Rust`) ABI --> rust/kernel/print.rs:21:1 | 21 | / unsafe fn rust_fmt_argument( 22 | | buf: *mut c_char, 23 | | end: *mut c_char, 24 | | ptr: *const c_void, 25 | | ) -> *mut c_char { | |________________^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#no_mangle_with_rust_abi = note: requested on the command line with `-D clippy::no-mangle-with-rust-abi` help: set an ABI | 21 | unsafe extern "C" fn rust_fmt_argument( | ++++++++++ help: or explicitly set the default | 21 | unsafe extern "Rust" fn rust_fmt_argument( | +++++++++++++ Thus enable it. In rare cases, we may need to use the Rust ABI even with `#[no_mangle]` (e.g. one case, before 1.71.0, would have been the `__rust_*` functions). In those cases, we would need to `#[allow(...)]` the lint, since using `extern "Rust"` explicitly (as the compiler suggests) currently gets overwritten by `rustfmt` [3]. Link: https://github.com/rust-lang/rust-clippy/issues/10347 [1] Link: https://github.com/Rust-for-Linux/linux/pull/967 [2] Link: https://github.com/rust-lang/rustfmt/issues/5701 [3] Reviewed-by: Trevor Gross <tmgross@umich.edu> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Link: https://lore.kernel.org/r/20230729220317.416771-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> diff 49a9ef76 Tue Apr 11 03:17:15 MDT 2023 Vinay Varma <varmavinaym@gmail.com> scripts: `make rust-analyzer` for out-of-tree modules Adds support for out-of-tree rust modules to use the `rust-analyzer` make target to generate the rust-project.json file. The change involves adding an optional parameter `external_src` to the `generate_rust_analyzer.py` which expects the path to the out-of-tree module's source directory. When this parameter is passed, I have chosen not to add the non-core modules (samples and drivers) into the result since these are not expected to be used in third party modules. Related changes are also made to the Makefile and rust/Makefile allowing the `rust-analyzer` target to be used for out-of-tree modules as well. Link: https://github.com/Rust-for-Linux/linux/pull/914 Link: https://github.com/Rust-for-Linux/rust-out-of-tree-module/pull/2 Signed-off-by: Vinay Varma <varmavinaym@gmail.com> Link: https://lore.kernel.org/r/20230411091714.130525-1-varmavinaym@gmail.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org> |
Completed in 2141 milliseconds