lint: emit proper diagnostic for unsafe binders in improper_ctypes instead of ICE

[SATVIKsynopsis]

Fixes #149719

This PR replaces the todo!("FIXME(unsafe_binder)") branch in the improper_ctypes lint with a proper diagnostic.

Previously, using an unsafe binder inside an extern "C" block caused an internal compiler error.
This fix now ensures that the compiler now emits a clear and stable error message explaining that types containing unsafe binders are not yet supported in FFI.

A new UI test (unsafe-binder-basic.rs) is included to ensure this behavior remains stable and prevent regressions.

[rustbot]

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

[mati865]

When using a chatbot to generate the code, you have to at least review it afterwards. _var is unused and should be removed.

[mati865]

Rerolling, as I have no expertise in this area.

@rustbot reroll

[reddevilmidzy]

// build-fail comment is not necessary. And if you use #![expect(incomple_feature)], the WARN will not occur.

[Kivooeo]

Hi, I see this is your first pull request - thank you for taking the time to submit it.

I’ve noticed the reasonable concerns raised by Mateusz above that this may have been AI-generated. If you'd like, you’re welcome to join the discussion below and help explain the reasoning behind the code decisions you made.

---

Also, I’d like to mention that we recently adopted a policy aimed at keeping reviews sustainable.

In short, it allows reviewers to redirect or close contributions that are overly burdensome to review - for example, when code or explanations appear inconsistent, contradictory, or don’t demonstrate an understanding of the existing codebase. You can read the full details here:

rust-lang/compiler-team#893

View changes since this review

[SATVIKsynopsis]

I have updated the PR with the following fixes:

removed the unused _vars binding as suggested.

adjusted the UI test as per the review (removed the unnecessary // build-fail comment ).

reran the full test suite to confirm the diagnostic and stderr output are stable.

I did use an AI tool initially to draft the change, but I fully reviewed, corrected, and refined the code myself.

all changes now reflect my understanding of the lint and the unsafebinder handling.

Please let me know if anything else should be improved.

[Kivooeo]

And some nits I'm less concerned about, but still think are worth mentioning

View changes since this review

[SATVIKsynopsis]

thanks for asking and happy to explain and answer your questions

i used skip_binder() because i only wanted to check the inner type that actually reaches the FFI boundary. The binder itself doesn’t matter for the FFI-safety check, since C doesn’t understand those binders. if I used the whole ty without skipping the binder, the lint wouldn’t look at the real inner type.

i understand your point about the diagnostic looking like just &().
if you prefer that the message keeps the unsafe part visible, i can update the code to print it that way.

[SATVIKsynopsis]

I see your point about using the fluent error messages instead of a raw string. I will take a look at the other arms and update this one to follow the same pattern so the diagnostic style stays consistent.

I will push the fixes shortly.

[SATVIKsynopsis]

that makes sense.

the current output only shows &(), while the span highlights the full unsafe &a (). I agree that the diagnostic should refer to the same type for consistency.

I will update the diagnostic to report unsafe &a () instead of just &(), and then adjust the .stder file to match the updated message.

Thanks for your clear explanation and feedback. it is really helpful as i am learning my way around the compiler codebase.

[SATVIKsynopsis]

Thanks for the detailed feedback I have updated the PR to address both concerns:

1. i changed the diagnostic to show the full type unsafe &a() instead of just the inner type &(). this makes it clearer that the entire unsafe binder construct is not supported in FFI.

2. switched from using a raw string to the fluent message system (added lint_improper_ctypes_unsafe_binder in messages.ftl) to keep it consistent with the other improper_ctypes handling thing.

i removed the skip_binder() call since we are not actually checking the inner type and we are just reporting that unsafe binders aren't supported in FFI contexts yet. the test output now correctly shows the full type in the error message.

let me know if there is anything else that needs adjusting. happy to learn and contribute.

[SATVIKsynopsis]

hi i have squashed the commits and cleaned up the history as requested.

these are the updates included in the final commit:

1. unified the diagnostic wording and switched to the fluent message system

2. updated the error to display the full unsafe &a() type for consistency

3. removed the unnecessary skip_binder() usage

4. improved the message wording as suggested

5. updated the ui test .stder fle to match the corrected diagnostic

thank you for the guidance and feedback it really helped me understand the lint behavior much better.
please let me know if anything else should be refined.

[Kivooeo]

It would be great if you could restore the two lines that were accidentally removed

View changes since this review

[SATVIKsynopsis]

I ran ./x.py test tidy for clean format file checking because this automatically runs after running git push. So, to double check formatting i ran ./x.py test tidy and it gave errors at these two locations which you mentioned so i had to give an extra newline to pass the tidy test.

[Kivooeo]

I just copied your PR and tried add them locally and tidy have nothing against this lines, can you show exact output?

[SATVIKsynopsis]

compiler/rustc_lint/src/types/improper_ctypes.rs. For this file when i remove the last newline it shows me this while running tidy. so for this only i gave the the newline so that tidy test passes.

and for the messages.ftl file i removed the newline in the previous commit only.

[Kivooeo]

Why the error in improper_ctypes.rs points at line 1055, when you need add new line after line 1020 (that was here before)

and for the messages.ftl file i removed the newline in the previous commit only

Yes, return it back please :) As you can see here all messages are spaced by a new line, you can't just remove it like this

[Kivooeo]

Squash please

[Kivooeo]

Tidy is failing because you change unrelated line, as I pointed it before

Why the error in improper_ctypes.rs points at line 1055, when you need add new line after line 1020

[Kivooeo]

Pay attention to line number here please #149730 (comment)

[Kivooeo]

You should preserve this last trailing line in the file

[SATVIKsynopsis]

I have checked the tidy issues and fixed them. Also fixed the newline and whitespaces issues. Please verify now.

[Kivooeo]

Nice, thanks!

Let's wait on CI and I will merge it afterwards

[Kivooeo]

Note: while I was patient and walked you through this process, other reviewers might handle things differently. In the future, similar PRs could be closed early if they require excessive back and forth for basic issues.

I'm not trying to scare you, just want you to be aware so you can better prepare for next time. If you plan to keep contributing, I'd recommend spending more time studying the surrounding code and understanding the problem fully before submitting.

[SATVIKsynopsis]

Thanks for the guidance and for taking the time to walk me through the review.
I understand the expectations better now, and I will make sure to study the surrounding code and prepare improvements more carefully in my future contributions.
I appreciate your patience. this was very helpful for me as a new contributor.

[Kivooeo]

@bors r+

[bors]

📌 Commit 0f4ec28 has been approved by Kivooeo

It is now in the queue for this repository.