Lint against treating `c_char` as `i8` or `u8`, for portability

[joshtriplett]

One common source of portability issues is making assumptions about whether c_char is i8 or u8. Code written for one platform may fail to build on another due because of this.

I think we could detect this fairly easily: we could add an attribute that means "yes, this is a type alias, but treat it as a slightly distinct type, and lint when matching it against the aliased type if not going through this type alias to do so".

This would help people avoid gratuitous portability issues.

[joshtriplett]

I've tagged this T-lang (because it's a proposed new lint and new attribute), and I've also tagged it for the three common architectures where char differs from the normal signedness.

[jyn514]

Another lint I'd like: treating i32 or i64 as c_long.

[the8472]

Should such a lint still fire if the code is cfg'd to a specific platform?

[est31]

cc #41619

[jyn514]

Should such a lint still fire if the code is cfg'd to a specific platform?

I would not expect it to, no.

[joshtriplett]

As a first pass, it would be acceptable if the lint triggered even in that case. It could be allow by default, for instance.

In other words I don't think it should be gated on the portability lint, though once the portability lint is available this should integrate with it.