rust: bindgen: upgrade to 0.65.1

* Rationale:

Upgrades bindgen to code-generation for anonymous unions, structs, and enums [7]
for LLVM-16 based toolchains.

The following upgrade also incorporates `noreturn` support from bindgen
allowing us to remove useless `loop` calls which was placed as a
workaround.

* Truncated build logs on using bindgen `v0.56.0` prior to LLVM-16 toolchain:

```
$ make rustdoc LLVM=1 CLIPPY=1 -j$(nproc)
  RUSTC L rust/core.o
  BINDGEN rust/bindings/bindings_generated.rs
  BINDGEN rust/bindings/bindings_helpers_generated.rs
  BINDGEN rust/uapi/uapi_generated.rs
thread 'main' panicked at '"ftrace_branch_data_union_(anonymous_at__/_/include/linux/compiler_types_h_146_2)" is not a valid Ident', .../proc-macro2-1.0.24/src/fallback.rs:693:9
...
thread 'main' panicked at '"ftrace_branch_data_union_(anonymous_at__/_/include/linux/compiler_types_h_146_2)" is not a valid Ident', .../proc-macro2-1.0.24/src/fallback.rs:693:9
...
```

* LLVM-16 Changes:

API changes [1] were introduced such that libclang would emit names like
"(unnamed union at compiler_types.h:146:2)" for unnamed unions, structs, and
enums whereas it previously returned an empty string.

* Bindgen Changes:

Bindgen `v0.56.0` on LLVM-16 based toolchains hence was unable to process the
anonymous union in `include/linux/compiler_types` `struct ftrace_branch_data`
and caused subsequent panics as the new `libclang` API emitted name was not
being handled. The following issue was fixed in Bindgen `v0.62.0` [2].

Bindgen `v0.58.0` changed the flags `--whitelist-*` and `--blacklist-*`
to `--allowlist-*` and `--blocklist-*` respectively [3].

Bindgen `v0.61.0` added support for `_Noreturn`, `[[noreturn]]`, `__attribute__((noreturn))` [4],
hence the empty `loop`s used to circumvent bindgen returning `!` in place of `()`
for noreturn attributes have been removed completely.

Bindgen `v0.61.0` also changed default functionality to bind `size_t` to `usize` [5] and
added the `--no-size_t-is-usize` [5] flag to not bind `size_t` as `usize`.

Bindgen `v0.65.0` removed `--size_t-is-usize` flag [6].

Link: llvm/llvm-project@19e984e [1]
Link: rust-lang/rust-bindgen#2319 [2]
Link: rust-lang/rust-bindgen#1990 [3]
Link: rust-lang/rust-bindgen#2094 [4]
Link: rust-lang/rust-bindgen@cc78b6f [5]
Link: rust-lang/rust-bindgen#2408 [6]
Closes: Rust-for-Linux#1013 [7]
Signed-off-by: Aakash Sen Sharma <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Ariel Miculas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[boqun: resolve conflicts because of Rust version bump]
Signed-off-by: Boqun Feng <[email protected]>

Author: Shinyzenith

rust/helpers.c

@@ -158,11 +158,11 @@ void rust_helper_init_work_with_key(struct work_struct *work, work_func_t func,
 EXPORT_SYMBOL_GPL(rust_helper_init_work_with_key);
 
 /*
- * `bindgen` binds the C `size_t` type as the Rust `usize` type, so we can
+ * `bindgen` binds the C `size_t` type the Rust `usize` type, so we can
  * use it in contexts where Rust expects a `usize` like slice (array) indices.
- * `usize` is defined to be the same as C's `uintptr_t` type (can hold any
- * pointer) but not necessarily the same as `size_t` (can hold the size of any
- * single object). Most modern platforms use the same concrete integer type for
+ * `usize` is defined to be the same as C's `uintptr_t` type (can hold any pointer)
+ * but not necessarily the same as `size_t` (can hold the size of any single
+ * object). Most modern platforms use the same concrete integer type for
  * both of them, but in case we find ourselves on a platform where
  * that's not true, fail early instead of risking ABI or
  * integer-overflow issues.