Meta issue: FFI attributes syntax

There are some FFI (and C FFI) specific attributes that we might want to add to Rust (e.g. see https://github.com/rust-lang/rust/pull/58327 and https://github.com/rust-lang/rust/pull/58315, amongst others).

We probably want to expose FFI attributes in a clean way.

Prefix vs no prefix

Many FFI attributes don't have a prefix, e.g., #[link_name], etc. Some like #[returns_twice] are required for correctness, and some like pure and const are optimization hints that might be ignored by the compiler. These do however have overloaded names that we might want to put into context to avoid confusion with, e.g., const fn.

Also, some attributes like pure and const have names with overloaded semantics that might make sense to disambiguate, e.g., instead of #[const] which is very similar to const fn, maybe #[ffi_const].

• Should we use prefixes at all?
• Should we do so for all FFI attributes or only for some?
• If we only use prexies for some attributes, do we decide for which on a 1 by 1 basis, or how do we decide this?

FFI can be used to interface with any language, but some attributes might only make sense when interfacing with some particular language.

• Should we take the language into account when prefixing attributes? (e.g. c_ffi or ffi::c)
• Should we just use a general prefix, e.g., ffi? (independent of language)
• Should we decide the prefix on a 1 by 1 basis? (should we define some rules for the prefixes? e.g. ffi and ffi_c vs ffi and c_ffi, etc.)

Option namespacing

Some FFI attributes might need to behave slightly different depending on the toolchain used to compile the code that's being interfaced via FFI.

For example, clang currently exposes both the [[const]] and [[gcc::const]] attributes. These currently are identical, but this separation is forward compatible with diverging semantics in the optimization hints that const has in the different toolchains. This is important both for interfacing clang binaries with gcc compiled libraries and vice-verse, and also, for not performing incorrect optimizations on programs that satisfy e.g. [[gcc::const]] requirements but not clang's [[const]].

• Should we already plan a syntax for platform toolchain disambiguation? (e.g. #[ffi::c::const(clang)] vs #[ffi::c::const(cranelift)] ?

Even if this is not RFC'ed right now, it might be worth it to have some plan for this in the pipe line in case it becomes necessary, and to make sure that merged RFCs are forward compatible with this. Otherwise we might end with #[c_ffi_const_clang] and #[gcc_ffi_c_const] or some similar zoo of attributes.

No source files or tests are named. Start by reviewing Rust PRs #58327 and #58315 and the questions in this meta issue; done requires an agreed, concrete syntax and scope for FFI attributes before an RFC can be developed.