improve c-variadic errors

[folkertdev]

tracking issue: #44930

Make some errors more specific, and clean up the logic

[rustbot]

joshtriplett is not on the review rotation at the moment.
They may take a while to respond.

[workingjubilee]

This raises questions about how we should handle the codegen for its self parameter, dyn compatibility, and so on. I would prefer we not get into those for now and continue to reject this case, please.

[folkertdev]

So reject in traits if there is a self parameter of some kind? reject in traits in general?

Previously also just normal associated methods/functions (like in impl S { }) were rejected, that is unproblematic right?

[workingjubilee]

I would prefer to continue to reject in all of the associated function cases for consistency and visit relaxation of this constraint in a deliberate fashion.

There have already been cases where people who work primarily with more frontend-oriented aspects of the compiler have misunderstood C's varargs as purely some syntactic quirk, and thus e.g. easily moved from function to function, instead of the nightmare it really is.

[folkertdev]

fair enough, I'll just add a custom error message then.

[folkertdev]

This now generates. At least we have tests now, none of this was exercised apparently.

error: associated functions cannot have a C-variadic argument
  --> $DIR/no-associated-function.rs:9:46
   |
LL |     unsafe extern "C" fn associated_function(mut ap: ...) -> i32 {
   |  

[folkertdev]

This is currently unreachable in practice, the parser already rejects ... in closures. So, this could be a span_bug instead?

[folkertdev]

huh, span_bug is only defined in rustc_middle, so we can't use that here. panic! or unreachable! also don't occur in this crate.

[workingjubilee]

The AST is weird on this point, yes.

[beetrees]

I think ideally we'd want to reject this in the parser itself (the same way we reject #[cfg(false)] fn f(u32) {}). However, it seems all the syntax gating for c_variadic has been done post-expansion meaning that this has compiled on stable since Rust 1.35.0 (although it seems unlikely anyone is relying on it):

#[cfg(any())] // Equivalent to the more recent #[cfg(false)]
unsafe extern "C" fn bar(_: u32, ...) {}

Given that this is essentially a stability hole, I think it would probably be ok to break it, but it would need a crater run and a lang FCP.

[workingjubilee]

Sigh. I hate post-expansion syntax gating.

[bors]

☔ The latest upstream changes (presumably #143556) made this pull request unmergeable. Please resolve the merge conflicts.

[folkertdev]

allright, let's handle _: ... separately then.

r? @workingjubilee now that this is no longer making any changes that are relevant for T-lang