improper_ctypes: extern "C" fns

[davidtwco]

cc #19834. Fixes#65867.

This pull request implements the change described in this comment.

cc @rkruppe@varkor@shepmaster

[rust-highfive]

r? @cramertj

(rust_highfive has picked a reviewer for you, use r? to override)

[hanna-kruppe]

Inline comments/questions about some of the allows. The number of in-tree false positives, especially due to generics, is a bit concerning but seems surmountable. I can think of a few ways to address it, in increasing order of complexity and pay-off:

• First of all, if possible, don't bail out on lifetime parameters. I've not given the code a careful reading w.r.t. this but it seems easier to not crash on those, and it would eliminate some false positives.
• Consider not trying to lint (type- and const-)generic functions. As they can't be no_mangle anyway, the only way they'll leak to C is if they get passed as function pointer, and we do check the types occurring in function pointers. (There could still be casts, e.g. to void *.)
• Check generic functions at monomorphization time. Errors at mono-time are a no-no but warnings should be fine. The downside is that legitimate warnings may be displayed too late and to the wrong people, but OTOH this is better than many false negatives and would increase precision.

[cramertj]

r? @varkor

[davidtwco]

Thanks for your comments @rkruppe, I’ll have time to revisit this later in the week and address them then.

[JohnCSimon]

Ping from triage
@davidtwco Is this still a draft PR? Can you please post your status?
Thank you.

[davidtwco]

@JohnCSimon This is still a draft PR. I’ve not had time to address the comments yet.

[davidtwco]

I've updated the PR so that the improper ctypes lint does not trigger for generic extern "C" fns. This should cut down on the false positives (it can always be done as a follow-up) and let us proceed with this PR and lint on the majority of cases.

[eddyb]

Are generic functions ignored, or just their type parameters considered FFI-safe for the purposes of the analysis?

[davidtwco]

Are generic functions ignored, or just their type parameters considered FFI-safe for the purposes of the analysis?

I skip functions with generics entirely. I suppose I could just ignore the generics and still lint on everything else. I don't think I can just consider the type parameters FFI-safe because the normalize_erasing_regions call in check_type_for_ffi_and_report_errors will panic because of them, before the call to check_type_for_ffi where I'd say they are FFI-safe.

rust/src/librustc_lint/types.rs

Lines 955 to 957 in 8318ef2

	// it is only OK to use this function because extern fns cannot have
	// any generic types right now:
	let ty = self.cx.tcx.normalize_erasing_regions(ParamEnv::reveal_all(), ty);

I suppose I could bail out early for type parameters before that call though..

[eddyb]

That call shouldn't ICE if you use a valid ParamEnv (i.e. tcx.param_env(def_id)).

[davidtwco]

Thanks, @eddyb. I've updated the PR so that type parameters are considered FFI-safe and the rest of the function will continue to be linted. See the test snippet shown below:

https://github.com/rust-lang/rust/blob/8b2d8e19ec74f55af2cfa31bc642c5927c43fdeb/src/test/ui/lint/lint-ctypes-fn.rs#L164-L179

[bors]

⌛ Testing commit 49e2403 with merge 3f0e164...

[bors]

☀️ Test successful - checks-azure
Approved by: rkruppe
Pushing 3f0e164 to master...

[jethrogb]

I'm now getting a warning on

extern"C"fn_f(_a:*mut*mut std::sync::Mutex<()>){}

Since the argument is just a thin raw pointer, I don't think the compiler should generate a warning here.