cg_llvm: Avoid some explicit casts to `*const c_char` by Zalathar · Pull Request #164017 · rust-lang/rust

Zalathar · 2026-10-09T06:26:29Z

Follow-up to cg_llvm: Avoid as_c_char_ptr in several places #163789

This is another application of the general principle noted in rustc_codegen_llvm::ffi:

Normally it's a good idea for Rust-side bindings to match the corresponding C-side function declarations as closely as possible. But when passing &str or &[u8] data as a pointer/length pair, it's more convenient to declare the Rust-side pointer as *const c_uchar instead of *const c_char. Both pointer types have the same ABI, and using *const c_uchar avoids the need for an extra cast from *const u8 on the Rust side.

For the changes in the main commit, a pointer/length string was being passed with *const c_char as the pointer type. This PR changes the Rust-side declaration to take *const c_uchar instead.

Changing the declared type avoids the need for explicit casts, making it easier to notice any accidental type errors.

A second commit also removes some pointer casts that were completely unnecessary.

There should be no change to compiler output.

rustbot · 2026-10-09T06:26:32Z

Some changes occurred in compiler/rustc_codegen_llvm/src/llvm/enzyme_ffi.rs

cc @ZuseZ4

rustbot · 2026-10-09T06:26:35Z

r? @mati865

rustbot has assigned @mati865.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 77 candidates
Random selection from 20 candidates

mati865

@bors r+ rollup

View changes since this review

rust-bors · 2026-10-09T07:22:27Z

📌 Commit de49a78 has been tentatively approved by mati865

It will be put into the queue for this repository once PR CI succeeds.

cg_llvm: Avoid some explicit casts to `*const c_char` - Follow-up to rust-lang#163789 --- This is another application of the general principle noted in `rustc_codegen_llvm::ffi`: > Normally it's a good idea for Rust-side bindings to match the corresponding C-side function declarations as closely as possible. But when passing `&str` or `&[u8]` data as a pointer/length pair, it's more convenient to declare the Rust-side pointer as `*const c_uchar` instead of `*const c_char`. Both pointer types have the same ABI, and using `*const c_uchar` avoids the need for an extra cast from `*const u8` on the Rust side. For the changes in the main commit, a pointer/length string was being passed with `*const c_char` as the pointer type. This PR changes the Rust-side declaration to take `*const c_uchar` instead. Changing the declared type avoids the need for explicit casts, making it easier to notice any accidental type errors. --- A second commit also removes some pointer casts that were completely unnecessary. There should be no change to compiler output.

…uwer Rollup of 4 pull requests Successful merges: - #163666 (Updates the expect message library/core/src/time.rs) - #164000 (When mentioning that closure doesn't implement trait, point at closure) - #164007 ([rustdoc] Prefer local paths over remote ones when foreign item is locally reexported) - #164017 (cg_llvm: Avoid some explicit casts to `*const c_char`)

cg_llvm: Avoid some explicit casts to `*const c_char` - Follow-up to rust-lang#163789 --- This is another application of the general principle noted in `rustc_codegen_llvm::ffi`: > Normally it's a good idea for Rust-side bindings to match the corresponding C-side function declarations as closely as possible. But when passing `&str` or `&[u8]` data as a pointer/length pair, it's more convenient to declare the Rust-side pointer as `*const c_uchar` instead of `*const c_char`. Both pointer types have the same ABI, and using `*const c_uchar` avoids the need for an extra cast from `*const u8` on the Rust side. For the changes in the main commit, a pointer/length string was being passed with `*const c_char` as the pointer type. This PR changes the Rust-side declaration to take `*const c_uchar` instead. Changing the declared type avoids the need for explicit casts, making it easier to notice any accidental type errors. --- A second commit also removes some pointer casts that were completely unnecessary. There should be no change to compiler output.

…uwer Rollup of 11 pull requests Successful merges: - #162652 (Syntactically reject leading parenthesized precise capturing lists in bare trait object types (`(use<…>)+`)) - #163337 (MIR move elimination [3/6]: PreciseLiveness) - #163954 (fix(bootstrap/darwin): fix rpath for distributed LLD) - #163956 (Pass the unremapped path to the `rustc` invocation for doctests) - #163634 (move overflow lint computation into decorator) - #163666 (Updates the expect message library/core/src/time.rs) - #163727 (rigid aliases to non-rigid for fully normalized check) - #163745 (replace `fully_monomorphized` with `cx.typing_env()`) - #164000 (When mentioning that closure doesn't implement trait, point at closure) - #164007 ([rustdoc] Prefer local paths over remote ones when foreign item is locally reexported) - #164017 (cg_llvm: Avoid some explicit casts to `*const c_char`)

cg_llvm: Avoid some explicit casts to `*const c_char` - Follow-up to rust-lang#163789 --- This is another application of the general principle noted in `rustc_codegen_llvm::ffi`: > Normally it's a good idea for Rust-side bindings to match the corresponding C-side function declarations as closely as possible. But when passing `&str` or `&[u8]` data as a pointer/length pair, it's more convenient to declare the Rust-side pointer as `*const c_uchar` instead of `*const c_char`. Both pointer types have the same ABI, and using `*const c_uchar` avoids the need for an extra cast from `*const u8` on the Rust side. For the changes in the main commit, a pointer/length string was being passed with `*const c_char` as the pointer type. This PR changes the Rust-side declaration to take `*const c_uchar` instead. Changing the declared type avoids the need for explicit casts, making it easier to notice any accidental type errors. --- A second commit also removes some pointer casts that were completely unnecessary. There should be no change to compiler output.

…uwer Rollup of 14 pull requests Successful merges: - #162652 (Syntactically reject leading parenthesized precise capturing lists in bare trait object types (`(use<…>)+`)) - #163337 (MIR move elimination [3/6]: PreciseLiveness) - #163954 (fix(bootstrap/darwin): fix rpath for distributed LLD) - #163193 (cfi: mangle `f128` as `e` rather than `g` on platforms without `_Float128`) - #163634 (move overflow lint computation into decorator) - #163666 (Updates the expect message library/core/src/time.rs) - #163727 (rigid aliases to non-rigid for fully normalized check) - #163745 (replace `fully_monomorphized` with `cx.typing_env()`) - #163912 (Fix debug assert failure in `note_obligation_cause_code_inner`) - #163972 (const-eval: ICE when we hit a non-const fn) - #164000 (When mentioning that closure doesn't implement trait, point at closure) - #164007 ([rustdoc] Prefer local paths over remote ones when foreign item is locally reexported) - #164017 (cg_llvm: Avoid some explicit casts to `*const c_char`) - #164025 (Less `CanonicalVarValues`)

cg_llvm: Avoid some explicit casts to `*const c_char` - Follow-up to rust-lang#163789 --- This is another application of the general principle noted in `rustc_codegen_llvm::ffi`: > Normally it's a good idea for Rust-side bindings to match the corresponding C-side function declarations as closely as possible. But when passing `&str` or `&[u8]` data as a pointer/length pair, it's more convenient to declare the Rust-side pointer as `*const c_uchar` instead of `*const c_char`. Both pointer types have the same ABI, and using `*const c_uchar` avoids the need for an extra cast from `*const u8` on the Rust side. For the changes in the main commit, a pointer/length string was being passed with `*const c_char` as the pointer type. This PR changes the Rust-side declaration to take `*const c_uchar` instead. Changing the declared type avoids the need for explicit casts, making it easier to notice any accidental type errors. --- A second commit also removes some pointer casts that were completely unnecessary. There should be no change to compiler output.

…uwer Rollup of 14 pull requests Successful merges: - #162652 (Syntactically reject leading parenthesized precise capturing lists in bare trait object types (`(use<…>)+`)) - #163337 (MIR move elimination [3/6]: PreciseLiveness) - #163954 (fix(bootstrap/darwin): fix rpath for distributed LLD) - #163193 (cfi: mangle `f128` as `e` rather than `g` on platforms without `_Float128`) - #163634 (move overflow lint computation into decorator) - #163666 (Updates the expect message library/core/src/time.rs) - #163727 (rigid aliases to non-rigid for fully normalized check) - #163745 (replace `fully_monomorphized` with `cx.typing_env()`) - #163912 (Fix debug assert failure in `note_obligation_cause_code_inner`) - #163950 (don't treat inherited opaques as defining) - #164000 (When mentioning that closure doesn't implement trait, point at closure) - #164007 ([rustdoc] Prefer local paths over remote ones when foreign item is locally reexported) - #164017 (cg_llvm: Avoid some explicit casts to `*const c_char`) - #164025 (Less `CanonicalVarValues`)

…uwer Rollup of 24 pull requests Successful merges: - #161998 ( Support type-relative assoc item paths in generic param defaults & const param types) - #162106 (Helpful suggestions for incorrect address-of mutability (2)) - #162652 (Syntactically reject leading parenthesized precise capturing lists in bare trait object types (`(use<…>)+`)) - #163337 (MIR move elimination [3/6]: PreciseLiveness) - #163938 (-Zassumptions-on-binders: rewrite alias outlives constraints more goodly) - #163939 (Better debug impls for some assumptions on binders types) - #163954 (fix(bootstrap/darwin): fix rpath for distributed LLD) - #163956 (Pass the unremapped path to the `rustc` invocation for doctests) - #164042 (Allow testing cg-gcc on any target) - #162443 (Do not retain `Normalization` goal errors in nested goals for `BestObligationVisitor:: non_trivial_candidates `) - #162908 (Fix - const parameters rejected when identical) - #163193 (cfi: mangle `f128` as `e` rather than `g` on platforms without `_Float128`) - #163634 (move overflow lint computation into decorator) - #163666 (Updates the expect message library/core/src/time.rs) - #163727 (rigid aliases to non-rigid for fully normalized check) - #163745 (replace `fully_monomorphized` with `cx.typing_env()`) - #163912 (Fix debug assert failure in `note_obligation_cause_code_inner`) - #163950 (don't treat inherited opaques as defining) - #163972 (const-eval: ICE when we hit a non-const fn) - #164000 (When mentioning that closure doesn't implement trait, point at closure) - #164007 ([rustdoc] Prefer local paths over remote ones when foreign item is locally reexported) - #164008 (properly ignore the current goal's usages) - #164017 (cg_llvm: Avoid some explicit casts to `*const c_char`) - #164025 (Less `CanonicalVarValues`)

Rollup merge of #164017 - Zalathar:char-ptr-cast, r=mati865 cg_llvm: Avoid some explicit casts to `*const c_char` - Follow-up to #163789 --- This is another application of the general principle noted in `rustc_codegen_llvm::ffi`: > Normally it's a good idea for Rust-side bindings to match the corresponding C-side function declarations as closely as possible. But when passing `&str` or `&[u8]` data as a pointer/length pair, it's more convenient to declare the Rust-side pointer as `*const c_uchar` instead of `*const c_char`. Both pointer types have the same ABI, and using `*const c_uchar` avoids the need for an extra cast from `*const u8` on the Rust side. For the changes in the main commit, a pointer/length string was being passed with `*const c_char` as the pointer type. This PR changes the Rust-side declaration to take `*const c_uchar` instead. Changing the declared type avoids the need for explicit casts, making it easier to notice any accidental type errors. --- A second commit also removes some pointer casts that were completely unnecessary. There should be no change to compiler output.

…uppe cg_llvm: Avoid all remaining uses of `as_c_char_ptr` Follow-up to: - rust-lang#163789 - rust-lang#164017 --- As explained in the previous PRs (and in the comments for `PTR_LEN_STR`), we can avoid the need for these casts by declaring the relevant FFI bindings to take `*const c_uchar`, which has the same ABI as `*const c_char`. This is more convenient at the call site, and makes it harder to mix up pointer/length strings and nul-terminated strings. There should be no change to compiler output.

Rollup merge of #164071 - Zalathar:as-c-char-ptr, r=hanna-kruppe cg_llvm: Avoid all remaining uses of `as_c_char_ptr` Follow-up to: - #163789 - #164017 --- As explained in the previous PRs (and in the comments for `PTR_LEN_STR`), we can avoid the need for these casts by declaring the relevant FFI bindings to take `*const c_uchar`, which has the same ABI as `*const c_char`. This is more convenient at the call site, and makes it harder to mix up pointer/length strings and nul-terminated strings. There should be no change to compiler output.

Zalathar added 2 commits October 9, 2026 17:20

Avoid some explicit casts to *const c_char

7b22d00

Remove some unnecessary pointer casts

de49a78

rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. F-autodiff `#![feature(autodiff)]` S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 9, 2026

rustbot assigned mati865 Oct 9, 2026

rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Oct 9, 2026

mati865 approved these changes Oct 9, 2026

View reviewed changes

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 9, 2026

JonathanBrouwer mentioned this pull request Oct 9, 2026

Rollup of 4 pull requests #164022

Closed

JonathanBrouwer mentioned this pull request Oct 9, 2026

Rollup of 11 pull requests #164024

Closed

JonathanBrouwer mentioned this pull request Oct 9, 2026

Rollup of 14 pull requests #164026

Closed

JonathanBrouwer mentioned this pull request Oct 9, 2026

Rollup of 14 pull requests #164027

Closed

JonathanBrouwer mentioned this pull request Oct 9, 2026

Rollup of 14 pull requests #164039

Closed

JonathanBrouwer mentioned this pull request Oct 9, 2026

Rollup of 24 pull requests #164052

Merged

rust-bors Bot merged commit 9a10987 into rust-lang:main Oct 9, 2026
14 checks passed

rustbot added this to the 1.101.0 milestone Oct 9, 2026

Zalathar deleted the char-ptr-cast branch October 9, 2026 23:44

Zalathar mentioned this pull request Oct 10, 2026

cg_llvm: Avoid all remaining uses of as_c_char_ptr #164071

Merged

Navigation Menu

Repository navigation

cg_llvm: Avoid some explicit casts to `*const c_char` - #164017

cg_llvm: Avoid some explicit casts to `*const c_char`#164017
rust-bors[bot] merged 2 commits into
rust-lang:mainfrom
Zalathar:char-ptr-cast

Zalathar commented Oct 9, 2026

Uh oh!

rustbot commented Oct 9, 2026

Uh oh!

rustbot commented Oct 9, 2026

Uh oh!

mati865 left a comment •

edited by rustbot

Loading

Uh oh!

rust-bors Bot commented Oct 9, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

Zalathar commented Oct 9, 2026

Uh oh!

rustbot commented Oct 9, 2026

Uh oh!

rustbot commented Oct 9, 2026

Uh oh!

mati865 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rust-bors Bot commented Oct 9, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

mati865 left a comment •

edited by rustbot

Loading