u32 has bad diagnostics with #[pg_extern]

[workingjubilee]

Check in a test that demonstrates this so that we are aware of improvements, and to prevent any regressions, as they used to be significantly worse.

This is a step towards resolving these issues:

• Obscure schema generator error for pg_extern function returning u32 #951
• Usability: bad error message for unsigned integer arguments #1536

[workingjubilee]

@nyurik This is a bit indirect still, isn't it? The spans are all fucked up.

[nyurik]

Thx for working on it! But yeah, trait not satisfied error is a bit of a rabbit hole... Perhaps it might be better to handle it explicitly? I am sure there will be plenty of surprises for such a common use case of an incorrect data type - so juts look at the input/return params in the PgExtern::new or nearby, and raise an error?

[workingjubilee]

nondet diagnostic output, adding cshim alters the hash I think

[workingjubilee]

Thx for working on it! But yeah, trait not satisfied error is a bit of a rabbit hole... Perhaps it might be better to handle it explicitly? I am sure there will be plenty of surprises for such a common use case of an incorrect data type - so juts look at the input/return params in the PgExtern::new or nearby, and raise an error?

Well, I'd rather not special-case the strings of any types (at least, any further than our code already does...), because given the sheer amount of FFI pgrx involves, people are very likely to do something like:

#[pg_extern]
fn pg_fn(arg: ffi::c_uint) -> ffi::c_ulong {

[workingjubilee]

This is not to say I'm against adding more diagnostic code here, I'd just rather do so in a more underhanded / generic way, like e.g. emitting structs with the name of the error I would want to emit and embedding the argument and return types in the struct.

[workingjubilee]

Nope, last one didn't fix it. Guess I'm waiting for better test infra or finding a way to emit a better diagnostic or rustc being less random about ordering here.

[nyurik]

How about just handle the well known simple types, e.g. u16, u32, ...?

[workingjubilee]

How about just handle the well known simple types, e.g. u16, u32, ...?

It feels like it lacks a satisfactory boundary.

[nyurik]

Well, it is not perfect, i agree, but if it will make the most common usecase more helpful... at least maybe give a warning?

[workingjubilee]

Well, it is not perfect, i agree,

It isn't about perfection. The problem in this case is that there are three type systems involved (Rust's, C's, and Postgres's), and people are going to have different opinions about what is "obvious" and "common". Without usage statistics (and cargo pgrx doesn't include telemetry), I can't rule anything out.

[workingjubilee]

I'm going to do some things that will significantly affect the diagnostics and might make them significantly worse or better, so this PR needs to serve its original purpose.

[nyurik]

Would the recently released diagnostics support help in this case? https://blog.rust-lang.org/2024/05/02/Rust-1.78.0.html#diagnostic-attributes